Lightning Routing

تريد آنا دفع ثمن قهوة، لكنها لا تملك قناة مع المقهى. لديها قناة مع بافل، ولبافل قناة أخرى مع المقهى. لذلك يمكن أن تمر الدفعة عبره: في القناة الأولى ينتقل جزء من الرصيد من آنا إلى بافل، وفي الثانية من بافل إلى المقهى. لا تنتقل العملة نفسها بين القنوات؛ بل تتغير أرصدتها بخطوات مترابطة. لذا يحتاج بافل إلى أموال تخصه وقابلة للاستخدام في الجانب الذي يدفع منه للمقهى. تختار محفظة المرسل أو عقدته الطريق إلى المستلم وتجهز تعليمات كل خطوة. يقدم المستلم البيانات اللازمة والميزات التي يدعمها، وقد يضيف معلومات عن الجزء الأخير غير المعلن. تمرر العقد الوسيطة الدفعة وفق التعليمات، ولا تبحث كل واحدة منها من جديد عن الطريق الكامل إلى الوجهة. [1] [4]

Gossip هو أسلوب نشر المعلومات بين العقد. يصف BOLT #7 إعلانات القنوات وتحديثاتها لكل اتجاه: الرسم الأساسي والنسبي، والفارق بين مواعيد انتهاء CLTV، والحدين الأدنى والأقصى للمبلغ، وعلامة الإتاحة. لكن الشروط المعلنة لا تثبت أن الطرف الآخر متصل الآن أو يملك أموالًا كافية. يشير CLTV هنا إلى مهلة تُحدَّد بارتفاع كتلة Bitcoin، أي ترتيبها في السلسلة، وليس بوقت دقيق على الساعة. ويمنح الفارق بين المهل الوسيط وقتًا للتصرف إذا تعطل تمرير الدفعة. [2]

لا تكشف السعة الإجمالية للقناة مقدار ما يستطيع كل طرف إرساله الآن. يعرف المرسل قنواته، ويعتمد في غيرها على التقديرات وسجل النجاحات والإخفاقات. لذلك يراعي البرنامج الرسوم واحتمال مرور الدفعة معًا. وقد تغير دفعة أخرى السيولة في أثناء ذلك، أي الأموال التي يمكن إرسالها في الاتجاه المطلوب. [4] [5]

تربط بين الخطوات مدفوعات HTLC، وهي مدفوعات مشروطة يتطلب إتمامها كشف السر الموافق لها. وإذا لم تكتمل الدفعة، يمكن استرداد أموالها بعد انتهاء المهلة. يبدأ الحساب بالمبلغ الذي سيصل إلى المستلم ويتجه إلى الخلف. يحتاج كل وسيط إلى تلقي المبلغ المخصص للعقدة التالية مع رسمه الخاص. ويجب أن ينتهي HTLC الوارد بعد الصادر بمدة كافية وفق فارق CLTV المطلوب. لذلك قد يزيد المسار الأطول التكلفة والمدة التي تظل فيها الأموال محجوزة عند حدوث مشكلة. [1] [2]

يستخدم onion routing وفق BOLT #4 بنية Sphinx، فتُشفَّر تعليمات كل خطوة على حدة. يعرف الوسيط الطرف السابق والتالي وتعليماته الخاصة. لا تكشف الحزمة وحدها المسار كله أو طوله أو موقع العقدة الدقيق فيه. ومع ذلك، قد يضعف تحليل حركة الاتصالات أو تعاون عدة عقد الخصوصية. [1]

قد تتعطل قناة مؤقتًا، أو تكون الرسوم أقل من المطلوب، أو CLTV غير صحيح، أو الطرف التالي غير متاح أو غير معروف. لا يتلقى المرسل سوى معلومات محدودة عن الخطأ. يمكن لبرنامجه خفض تقييم المسار وإعادة حسابه والمحاولة مجددًا. هذا ليس غرامة مالية تُدفع إلى العقدة، ونتيجة واحدة ليست حكمًا دائمًا على موثوقيتها. [1] [4]

لا يكفي العثور على اتصالات: يجب أن تقبل كل خطوة HTLC وأن تتوافر فيها أموال قابلة للاستخدام بالقدر الكافي في الاتجاه المطلوب. قد يُحتفظ بجزء من الرصيد احتياطيًا، أو يُحجز في مدفوعات لم تكتمل بعد. ويحدد الحقلان التقنيان htlc_minimum_msat وhtlc_maximum_msat أيضًا الحدين الأدنى والأقصى لمبلغ HTLC واحد في ذلك الاتجاه. وحدة msat هي جزء من ألف من الساتوشي، والساتوشي أصغر وحدة للمبلغ على سلسلة Bitcoin. وحتى الحد المعلن المرتفع لا يثبت أن السيولة المطلوبة متاحة الآن. لذلك قد تمنع قناة واحدة غير ملائمة استخدام المسار كله. [2]

إذا كان المستلم يدعم basic MPP، أي تقسيم دفعة واحدة إلى عدة أجزاء، يمكن للمرسل توزيع المبلغ الإجمالي، الذي يُسمّى في البروتوكول total_msat، على عدة مسارات. ينتظر المستلم الأجزاء اللازمة ويسويها معًا. يستفيد ذلك من السيولة الموزعة بين القنوات، لكن MPP لا يخلق سيولة جديدة. ويزداد عدد HTLC والمحاولات، وقد تزيد الرسوم. [1]

يمكن لـ route hints في BOLT #11 تزويد المرسل ببيانات الخطوات الأخيرة غير المعلنة. أما route blinding المستخدم في BOLT #12 فيتيح بدلًا من ذلك جزءًا نهائيًا مشفرًا عبر عقدة دخول تسمى introduction point. يظل على المرسل إيجاد طريق قابل للاستخدام إلى هذه النقطة واستيفاء شروط الرسوم وCLTV المجمعة. تحسن الخصوصية لا يضمن وصول الدفعة. [3] [6] [1]

في المدفوعات اليومية، تتولى المحفظة البحث عن المسار. وتفيد التفاصيل التالية مشغّلي العقد خصوصًا، وكذلك عند البحث عن أسباب المشكلات المتكررة. سجل البرنامج وإصداره، والمبلغ، والحد الأقصى للرسوم وCLTV، وعدد المحاولات، والمسارات المستخدمة، وزمن الإتمام، وسبب الفشل الدقيق. قارن الزوج نفسه من العقد في أوقات متقاربة. يصف النجاح دفعة محددة في حالة معينة للشبكة، وليس تقييمًا عامًا دائمًا. [4] [5]