55 / 736HTLC

HTLC

Hashed Timelock Contract — شرط التجزئة والوقت

يربط HTLC الدفع بكشف القيمة السرية الصحيحة، ويوفر مسارًا لاستعادة الأموال إذا لم يكتمل الدفع. في Lightning Network يتيح الدفع عبر وسطاء دون الاعتماد على وعودهم وحدها. لكن هذه الحماية تظل بحاجة إلى توقيعات صحيحة وتصرف في الوقت المناسب.

HTLC اختصار لـ Hashed Timelock Contract. هو دفع مشروط: يتطلب أحد المسارات قيمة سرية تطابق تجزئتها، أي بصمتها الرقمية، قيمة معروفة مسبقًا؛ ويسمح مسار آخر باستعادة الأموال بعد استيفاء شروط زمنية. تسمى القيمة السرية preimage، وليست كلمة مرور المحفظة. معرفتها لا تغني عن التوقيعات المطلوبة، ومرور الوقت لا يعيد المال تلقائيًا.

تريد آنا إرسال ⁦20 000 sat⁩ إلى بافل عبر Lightning Network. Sat اختصار لـ satoshi، أصغر وحدة للبيتكوين على السلسلة. ليس بينهما قناة دفع مشتركة، لكن كليهما يملك اتصالًا مناسبًا عبر إيفا. القناة اتفاق بين مشاركين على توزيع بيتكوين، يمكن تحديثه دون تسجيل كل دفعة في كتلة. تعرض إيفا على بافل دفعة مشروطة قدرها ⁦20 000 sat⁩، وتعرض آنا على إيفا ⁦20 010 sat⁩. يمثل الفرق، ⁦10 sat⁩، رسم إيفا في هذا المثال المبسط. إنها تغييرات مترابطة في رصيدي قناتين، وليست العملة المنفردة نفسها تنتقل عبرهما. يعرف بافل سرًا يسمح له باستيفاء شرطه، ثم تستطيع إيفا استخدام القيمة نفسها مع آنا. فلا تضطر إلى الدفع لبافل أولًا بصورة لا رجعة فيها اعتمادًا على وعده وحده. الأرقام لتوضيح الآلية، وليست رسومًا معتادة أو موصى بها. [1]

يجهّز بافل للدفع قيمة سرية عشوائية بطول 32 بايت تسمى payment_preimage. تحسب SHA-256 منها قيمة payment_hash. يسهل التحقق من أن القيمة المكشوفة تعطي البصمة الصحيحة، بينما يكون استخراج سر اختير جيدًا من البصمة وحدها غير ممكن عمليًا. تحتوي فاتورة BOLT 11 المعتادة، أي طلب دفع Lightning، على التجزئة في الحقل p، لا على preimage نفسها. عندما يفي بافل بشرط الدفع، يعود السر عبر المسار ويربط عقود HTLC المعنية. أما payment_secret في الحقل s فهو قيمة مختلفة تساعد المستلم على معالجة الدفع بصورة صحيحة، ولا تحل محل preimage. لا تمثل أي من هذه القيم Seed Phrase (كلمات استعادة المحفظة) أو المفتاح الخاص للمحفظة. [1] [4]

لو كانت للدفعتين المهلة نفسها، لأمكن أن يكشف بافل السر متأخرًا إلى حد لا يسمح لإيفا بتحصيل الدفعة الواردة. لذلك تنتهي مهلة HTLC الوارد من آنا بعد مهلة HTLC الصادر من إيفا إلى بافل. يمنح هذا الفرق، المسمى cltv_expiry_delta، إيفا هامشًا. تحتاجه أيضًا إذا توقف الطرف الآخر عن الرد واضطرت إلى تنفيذ الاتفاق بمعاملات بيتكوين على السلسلة. يقاس الهامش بالكتل، لا بالدقائق الدقيقة، ويجب أن يراعي التأخير وإعادة تنظيم السلسلة. تتولى البرمجيات وقواعد القناة ضبطه بأمان؛ والهامش الصغير جدًا يعرّض الأموال للخطر. في إعادة تنظيم السلسلة، يُستبدل جزء منها بفرع صالح آخر، مما قد يغيّر تأكيدات المعاملات السابقة. [1]

في Lightning، يشير cltv_expiry إلى ارتفاع كتلة، أي موقعها في السلسلة. ليس Unix timestamp (تاريخ ووقت ممثلان بعدد من الثواني) ولا مدة صلاحية فاتورة BOLT 11 المقاسة بالثواني. بعد استيفاء الشروط الزمنية، قد يتاح مسار timeout للتسوية دون السر. لا تتحرك الأموال وحدها: على عقد Lightning، وهي البرامج التي تدير قنوات الدفع، إتمام تحديث القناة بصورة صحيحة أو استخدام المعاملة المناسبة على السلسلة. كذلك لا تتوقف preimage الصحيحة عن العمل تلقائيًا عند انتهاء المهلة. إذا لم يُنفق المخرج نفسه، أي مبلغ تحكمه قواعد إنفاق، بطريقة أخرى بعد، فقد تتنافس مسارات مسموحة لإنفاقه؛ ولا يمكن تأكيد الإنفاقين في سلسلة صحيحة واحدة. لذا يعد التصرف في الوقت المناسب جزءًا من الأمان. [1] [4] [5]

يربط HTLC الشروط، لكنه لا يجعل أي مبلغ يمر عبر أي مسار. تحتاج إيفا أموالًا كافية في الاتجاه الصادر، أي السيولة، ومكانًا لإضافة HTLC معلّق آخر. قد توقف الحدود أو الرسوم أو عقدة غير متاحة عملية الدفع. وإلى أن تُحسم المحاولة المعلقة بصورة صحيحة، قد يبقى جزء من الأموال مرتبطًا بها. تصف حالة المحفظة المحاولة كاملة؛ ولا تكفي رسالة منفردة لإثبات نتيجتها. كشف preimage ليس تأكيدًا لمعاملة بيتكوين. يُسوّى دفع Lightning المعتاد الناجح بتحديث القنوات، دون تسجيل كل دفعة في كتلة جديدة. [1] [3]

الأقسام التالية مرجع تقني. تسجل حالة القناة صاحب الحق في كل مبلغ وعقود HTLC التي ما زالت معلّقة. Commitment transaction معاملة بيتكوين موقعة تسمح بتنفيذ تلك الحالة على السلسلة. تقترح update_add_htlc الإضافة فقط؛ وتبلغ update_fulfill_htlc بالوفاء وupdate_fail_htlc بالفشل. لا يكفي إعلان التغيير. عبر commitment_signed وrevoke_and_ack، يتبادل الطرفان توقيعات الحالة الجديدة والمعلومات التي تجعل استخدام الحالة القديمة غير آمن. وفق BOLT 2، يجب أن يقبل كلاهما التغيير المعني بصورة غير قابلة للإلغاء قبل أن يعتمد عليه التزام تالٍ. اتفاق المشاركين هذا ليس تأكيدًا في كتلة. أما تمويل القناة وإغلاقها عند الحاجة فيعتمدان على معاملات بيتكوين. [1]

الحقول هي القيم المفردة في الرسالة. Millisatoshi جزء من ألف من satoshi، ووحدة حساب داخل Lightning؛ لا يمكن إنفاق هذا الجزء منفردًا على سلسلة بيتكوين. تتكون الحقول الأساسية لرسالة update_add_htlc من channel_id وid وamount_msat وpayment_hash وcltv_expiry وonion_routing_packet. تُقاس amount_msat بوحدة millisatoshi. تفحص العقدة حدود القناة والسيولة المتاحة وشروط التمرير، ويملك HTLC الصادر معلماته الخاصة. لا يجوز عرض HTLC المقابل قبل تثبيت إضافة الوارد بصورة غير قابلة للإلغاء وفق BOLT 2. [1]

يضع Onion routing تعليمات كل وسيط داخل طبقات مشفرة منفصلة. تحصل إيفا على ما تحتاجه لخطوتها، لا قائمة مكشوفة بجميع المشاركين. تفك العقدة تشفير طبقة onion الخاصة بها وتتحقق من سلامتها. في المسار العادي غير المعمّى، تقارن amt_to_forward وoutgoing_cltv_value بالمبلغ الوارد والرسم والفارق الزمني المطلوب. لا تكشف الحزمة لها المسار كله. لكن هذا لا يستبعد ربط حركة البيانات أو استنتاج الهوية بوسائل أخرى؛ لا يضمن onion routing إخفاء الهوية المطلق. [3]

المخرج مبلغ له قواعد إنفاق مكتوبة بلغة Script. يشير offered وreceived إلى HTLC المعروض والمستلم من منظور مشارك القناة. المرحلة الثانية معاملة لاحقة، ويفرض CHECKSEQUENCEVERIFY (CSV) انتظارًا يبدأ من تأكيد المخرج المراد إنفاقه. يسمح مفتاح الإبطال بمعاقبة نشر حالة قديمة سبق إبطالها. يميّز BOLT 3 مخرجات offered وreceived ومسارات HTLC-success أو HTLC-timeout. لا تكفي مجرد معرفة تجزئة؛ تلزم التوقيعات وpreimage والشروط الزمنية ذات الصلة. يخضع المخرج المحلي للمرحلة الثانية لتأخير CSV مقداره to_self_delay، بينما يتيح مفتاح الإبطال الصحيح للطرف المقابل فرع العقوبة دون هذا التأخير. يعتمد Script الدقيق على نوع القناة. [2] [6]

يعني trimming أن HTLC صغيرًا لا يتحول إلى مخرج مستقل عند نقل حالة القناة إلى السلسلة. Dust اسم لهذه المبالغ الصغيرة، ويقيس dust exposure قيمتها الإجمالية الخاضعة لهذا القيد. إذا كان المبلغ بعد رسم المرحلة الثانية المنطبق أقل من dust_limit_satoshis، فلا تنشئ معاملة الالتزام مخرج HTLC. تعتمد القواعد على النوع المتفق عليه: لا يوجد هذا الرسم للمرحلة الثانية مع option_anchors وzero_fee_commitments؛ وقد يوجّه zero_fee_commitments القيمة المستبعدة إلى shared_anchor. لا يمكن المطالبة بصورة منفصلة على السلسلة بمخرج غير موجود. ويشكل مجموع هذه HTLC مقدار dust exposure. [2] [1]

الفحص التالي موجّه لمشغلي العقد والمطورين. يحوّل فك الترميز السجل إلى حقول مقروءة؛ ولا يرسل شيئًا أو يثبت بمفرده استيفاء جميع الشروط. قارن amount_msat وpayment_hash وcltv_expiry الواردة والصادرة، وتحقق من preimage باستخدام SHA-256. تابع كذلك commitment_signed وrevoke_and_ack والحالة النهائية، لا رسالة fulfill/fail واحدة فقط. عند التنفيذ على السلسلة، فك ترميز معاملة الالتزام الفعلية وتحقق من وجود المخرج والفرع المستخدم وHTLC-success/HTLC-timeout. افحص التوقيعات والشروط الزمنية والتأكيدات؛ فك الترميز وحده لا يثبت الصلاحية. [1] [2]

للحصول على صورة أوضح، اقرأ هذا المدخل مع Lightning Network, Payment Channel, Timelock, Hash, CLTV, CSV. تشير إلى هذا المدخل أيضًا Timelock, Payment Channel, سيولة Lightning, Lightning Routing.

DOC · 001BOLT 2 — Channel state and HTLC handlingمواصفة DOC · 002BOLT 3 — HTLC transaction scripts and trimmingمواصفة DOC · 003BOLT 4 — Onion routing and payload validationمواصفة DOC · 004BOLT 11 — Payment hash and invoice expiryمواصفة DOC · 005BIP 65 — CHECKLOCKTIMEVERIFYمواصفة DOC · 006BIP 112 — CHECKSEQUENCEVERIFYمواصفة
تمت المراجعة: المصادر أولًا · ليست نصيحة استثمارية