Rusty Russell

تبدأ المشاريع الكبيرة أحياناً بخطوة متواضعة. يستعيد مقال Blockstream المؤرخ في 9 يونيو 2026 أول commit لـRussell في 26 مايو 2015: أداة صغيرة لإنشاء رسالة فتح قناة. والـcommit هو تغيير مسجل في تاريخ الشيفرة. نما ذلك الاختبار المبكر إلى Core Lightning، وساهم Russell في البرنامج واختباراته وإرشاد مطوّرين آخرين. يصف المقال أيضاً مغادرته بعد أحد عشر عاماً. ولا يعلن بذلك نهاية جميع مساهماته المستقبلية في المصدر المفتوح، كما لا يجعل الدور القيادي السابق سلطة دائمة على الشبكة. [1]

تخيّل مقهى وزبوناً يستخدمان برنامجين مختلفين. لا ينبغي أن يتوقف الدفع على اختيارهما المزوّد نفسه. يحتاجان إلى قواعد مشتركة للرسائل ومعناها، وهذا ما تصفه مواصفات BOLT في Lightning. قاد Russell عملية تطويرها التعاونية ودعم قابلية التشغيل البيني، أي قدرة التطبيقات المختلفة على العمل معاً. يقبل المستودع العام المقترحات والتعليقات. لكن حتى المساهم البارز لا يستطيع وحده فرض تغيير على جميع العقد؛ يجب أن تتحول القواعد إلى برامج فعلية واستخدام حقيقي. [1] [2]

قد يفهم برنامجان الفقرة نفسها بصورة مختلفة. يوفر lnprototest، الذي أنشأه Russell، أدوات بلغة Python لكتابة سيناريوهات وتجربة الردود على رسائل البروتوكول. يميز README، الوثيقة التمهيدية للمشروع، بين مشغّل وهمي والاختبار مع تطبيق حقيقي. تساعد المحاكاة في إعداد الاختبار، لكن نجاحها وحده لا يثبت سلوك عقدة فعلية. المهم معرفة ما شُغّل فعلاً وأي مواقف اختُبرت. وحتى نجاح مجموعة سيناريوهات لا يعادل تدقيقاً كاملاً لكل عيب ممكن. [3]

يمكن للمقهى وفق ⁦BOLT 12⁩ نشر عرض قابل لإعادة الاستخدام، مثل رمز QR. ترسل محفظة الزبون بناءً عليه رسالة invoice_request وتحصل على فاتورة محددة، أي طلب دفع يحتوي بيانات هذه العملية. يأتي الدفع بعد ذلك. يمكن إعادة استخدام العرض مع الحصول على فواتير فردية. ولا يعني ذلك اعتبار فاتورة سبق استخدامها طلباً جديداً في كل شراء. الفصل بين العرض والطلب والفاتورة يجعل الدفع مريحاً دون خلط العمليات المختلفة. [4]

يظهر هذا الفصل في Core Lightning أيضاً. يتصل الأمر fetchinvoice بمصدر العرض ويحصل على فاتورة. وقد يعرض الحقل changes اختلافات عن العرض، مثل المبلغ أو الوصف. الاستجابة الناجحة لا ترسل مالاً. الأمر يشبه استلام حساب المقهى: تتحقق أولاً مما ستدفع مقابله ومن المبلغ. على المحفظة معالجة الشروط المستلمة ثم بدء الدفع على نحو منفصل. اكتمال الحصول على الطلب ليس اكتمالاً لتسديده. [5]

تفرق وثائق pay بين complete وpending وfailed: مكتمل، قيد الانتظار، وفاشل. الانتظار ليس نجاحاً للدفع. وتميز amount_msat، المبلغ الذي تلقاه المستلم، عن amount_sent_msat، إجمالي المرسل شاملاً الرسوم. تعني msat وحدة millisatoshi، وهي جزء من ألف من satoshi. لذلك قد يدفع الزبون رسماً فوق ما يتلقاه المقهى. تصف الوثائق pay الآن بأنه واجهة متقادمة وتشرح الانتقال إلى xpay. المقصود هنا فهم الحالات والمبالغ، لا تثبيت إصدار محدد؛ ينبغي قراءة النتيجة وفق البرنامج المستخدم فعلاً. [6]

عندما يعيد المقهى المال لا يشغّل الدفعة الأصلية بالعكس. تصف ⁦BOLT 12⁩ أيضاً المسار المعاكس: يعلن التاجر المبلغ الذي يريد إرساله، ويقدم الزبون فاتورة، ويتحقق التاجر من invoice_node_id، معرّف العقدة التي سيدفع لها. ثم يرسل دفعة جديدة إلى الزبون. هذا لا يلغي التحويل الأصلي ولا ينشئ تلقائياً حقاً في الاسترداد. يوفر البروتوكول طريقة التنفيذ؛ أما السبب والشروط فيتفق عليهما الأطراف بصورة مستقلة. [4]

عند النزاع، من المفيد معرفة ما يثبته الدليل تحديداً. توضح ⁦BOLT 12⁩ أن preimage، القيمة السرية المطابقة للبصمة في طلب الدفع، يمكنها إثبات تسديد الفاتورة. لكن بعد نشرها يستطيع شخص آخر عرضها أيضاً؛ فهي لا تحدد وحدها من أرسل المال. يتيح مفتاح في الطلب إثبات من طلب الفاتورة، لكنه لا يتحقق تلقائياً من الهوية المدنية لذلك الشخص. الفاتورة المسددة والسيطرة على المفتاح وهوية الزبون معلومات مختلفة. [4]