Lightning Watchtower

لدى آنا وبافل قناة دفع: أموالهما مقفلة معًا في Bitcoin، وتغيّر مدفوعات Lightning كيفية توزيعها. يدفع بافل لآنا، ويتفقان على الرصيدين الجديدين ويلغيان الحالة القديمة. ثم ينقطع الإنترنت لدى آنا. لو نشر بافل الحالة القديمة، فقد يحاول استرجاع أموال أنفقها بالفعل. تستطيع آنا الاستعانة بخدمة Lightning Watchtower لمثل هذه الحالة. ترسل عقدتها مسبقًا بيانات مشفرة لحماية الحالات الملغاة. وعندما تتعرف الخدمة على المعاملة المعنية في السلسلة، يمكنها بث معاملة استرداد دون أن تكون آنا متصلة. لكنها لا تنفذ المدفوعات بدلًا منها ولا تصلح اتصال عقدتها. [1] [8]

لكل توزيع متفق عليه للأموال commitment transaction، أي معاملة موقعة يمكن بها إغلاق القناة على سلسلة Bitcoin. عند تحديث الحالة، يتبادل المشاركان معلومات تتيح معاقبة نشر الحالة السابقة الملغاة. نتحدث هنا عن هذا النوع من القنوات الذي يعتمد آلية عقوبة. إذا استخدم بافل الحالة الحالية الصالحة، فله أن يغلق القناة من طرف واحد حتى أثناء انقطاع آنا. ليس دور Watchtower منع هذا الإغلاق. يتدخل ضد حالة ملغاة محددة، سواء نشرها بافل عمدًا أم بالخطأ من نسخة احتياطية قديمة. العبرة بإلغاء الحالة، لا بعمر المعاملة. [1] [8]

Seed Phrase نسخة احتياطية على شكل كلمات، تتيح استعادة المفاتيح الخاصة اللازمة لتوقيع المدفوعات. وLND أحد البرامج المستخدمة لتشغيل عقدة Lightning. لا تعطي آنا الخدمة Seed Phrase ولا المفاتيح الخاصة لمحفظتها كلها. تقدم معلومات وتوقيعات محدودة لتدخل معين؛ وتسمى هذه الحزمة في LND باسم JusticeKit. معاملة الاسترداد، المسماة justice transaction، تعيد الأموال المحمية وفق شروط أُعدّت مسبقًا. لا يمنح ذلك Watchtower حرية إنفاق عملات آنا الأخرى. في النموذج الذي لا يمنح الخدمة مكافأة، تُخصم رسوم معاملة Bitcoin من المبلغ المحمي. يتضمن الكود أيضًا أنواعًا تمنح البرج مكافأة، لكن وجودها وحده لا يثبت أن مشغّلًا معينًا يقدم خدمة مدفوعة. [3] [4] [5]

حتى يساعد Watchtower، يجب أن يستلم البيانات اللازمة فعلًا. لا يكفي إدخال عنوانه في الإعدادات أو رؤية مهمة في قائمة انتظار الإرسال. العميل، أي الجزء من عقدة آنا الذي يتواصل مع البرج، يحتاج إلى إقرارات باستلام التحديثات. قد ينقطع الاتصال، أو تنفد سعة اتفاق التخزين المسمى session، أو تُرفض نسخة احتياطية. لذلك تحتاج آنا أيضًا إلى متابعة التحديثات التي لم تصل والأخطاء. وحتى قبول البيانات لا يضمن النجاح: يجب أن يواصل البرج متابعة السلسلة الصحيحة وأن تُؤكّد معاملة تدخله في كتلة في الوقت المناسب. [6] [8]

إذا فقدت آنا جهازها، فلن تستعيده من Watchtower. تراقب الخدمة إساءة استخدام الحالات الملغاة، لكنها لا تستعيد المحفظة ولا تعالج سرقة المفاتيح. يستخدم LND نظام Static Channel Backup ‏(SCB) لاسترداد القنوات. ويساعد مع seed المحفظة على استعادة الأموال بإغلاق القنوات، لا على مواصلة العمل من الحالة الدقيقة التي توقفت عندها العقدة. ليس SCB نسخة من كل تحديث، ولا الحزمة المشفرة المرسلة إلى البرج. وتشغيل قاعدة channel.db قديمة دون اتباع إجراء الاسترداد الصحيح خطير خصوصًا: فقد تنشر العقدة حالتها الملغاة بنفسها. جهّز النسخ الاحتياطية وفق وثائق المحفظة وإصدارها المحدد. [7]

يحدد مخرج المعاملة مبلغًا والشروط التي تسمح بإنفاقه. تعمل الحماية لأن من ينشر حالة قناته لا يستطيع إنفاق مخرجه المؤجل فورًا. يسمي BOLT 3 هذا المخرج to_local، وفترة الانتظار to_self_delay. أما CSV فهو القاعدة التي تقيس التأخير بالكتل منذ تأكيد المخرج. يستطيع الطرف الآخر، بمفتاح الإلغاء الصحيح، استخدام مسار العقوبة دون هذا الانتظار. وهكذا يحصل Watchtower على مهلة تتيح له التحرك أولًا. بانتهاء التأخير لا يختفي مسار العقوبة، لكن الطرف الآخر يصبح قادرًا أيضًا على إنفاق الأموال. تتوقف النتيجة على أي الإنفاقين المتعارضين يتأكد بصورة صالحة. لذلك لا يكفي بث معاملة الاسترداد، كما أن عدد الكتل لا يعني عددًا دقيقًا من الساعات. [1] [9]

قبل اختيار الخدمة، تحقق مما تحميه فعلًا. HTLC مدفوعات مشروطة قد تبقى معلقة داخل القناة؛ ومراقبة الأرصدة لا تثبت أنها مشمولة بالحماية. يشير Dust هنا إلى مخرج أصغر من أن يُدرج في المعاملة المعنية. يجهز backupTask المتحقق منه في LND ⁦v0.21.3-beta⁩ مخرجات to_local وto_remote الموجودة وغير المصنفة dust في commitment الملغى. ولا يشمل حماية عامة لجميع مخرجات HTLC؛ إذ تصف الوثائق المعنية ذلك بأنه توسع مستقبلي. Bitcoin Script هي اللغة التي تصف شروط إنفاق المخرج. وإمكانية إنفاق مخرج عبر مسار العقوبة لا تعني أن برجًا معينًا قد تلقى البيانات اللازمة أو أنه يستطيع تنفيذ هذه الحماية. [3] [5]

لا تتطلب الحزمة المشفرة أن يقرأ البرج أرصدة آنا كلها باستمرار. يبحث عن تطابق بعلامة قصيرة، ويفك تشفير البيانات بمعلومات من المعاملة التي يتعرف عليها. ما يلي مرجع تقني لإصدار محدد من LND؛ يعني txid معرّف المعاملة، وblob حزمة بيانات. في LND ⁦v0.21.3-beta⁩ يتكون BreachHint من أول 16 بايت من SHA-256 لمعرف txid الثنائي. وينتج BreachKey من تطبيق SHA-256 على معرف txid الثنائي نفسه موصولًا بنفسه. ليس المقصود أول 16 حرفًا من txid المعروض ولا نصفه الأول ببساطة. يشفر العميل JusticeKit؛ وعند معرفة المعاملة المطابقة يمكن اشتقاق المفتاح وفك تشفير البيانات. [2] [3]

تشغيل برج للآخرين يختلف عن إسناد مراقبة قنواتك إلى برج. هذه الإعدادات لمشغّلي LND؛ وRPC واجهة يتلقى البرنامج من خلالها الأوامر. يفصل LND بين watchtower.active للخادم وwtclient.active للعميل. تشغيل الخادم وحده لا يضبط نسخ قنواتك الاحتياطية لدى برج آخر. يعرض lncli tower info حقول pubkey وlisteners وuris للخادم؛ ويسجل lncli wtclient add برجًا للعميل. يختلف المفتاح العام للبرج عن مفتاح عقدة Lightning. تحقق من الشبكة وإمكانية الوصول إلى العنوان ودعم RPC في النسخة المبنية المستخدمة. [5]

يجب أن يدفع التدخل تكلفة مساحة في كتلة Bitcoin. الساتوشي أصغر وحدة من البيتكوين. ويقيس البايت الافتراضي حجم المعاملة مع مراعاة اختلاف أوزان أجزائها. يُعبّر عن المعدل بعدد الساتوشي لكل بايت افتراضي من حجم المعاملة، لا بنسبة من الأموال المحمية. في LND ⁦v0.21.3-beta⁩ يحدد حقل sweep_sat_per_vbyte في policy وsession المعدل بوحدة sat/vB. تقلل الرسوم المبلغ المعاد. قد يرفض backupTask حالة ذات قيمة صغيرة جدًا أو معلمات session غير مناسبة؛ فليست كل مهمة مجهزة نسخة احتياطية مؤهلة. تغيير الإعداد لاحقًا لا يثبت تغير المعاملات الموقعة سابقًا، وقد يؤدي المعدل غير الكافي إلى تأخير الاستجابة. [3] [6]

لا يفيد برج ثانٍ عند تعطل الأول إلا إذا كان قد تلقى البيانات اللازمة بنفسه. ويشمل الاستقلال الاتصال والمشغّل، لا مجرد اختلاف اسم الخدمة. يمكن لعدة أبراج مستقلة مع المراقبة الذاتية أن تحد من أثر تعطل واحد. لكن تحقق من التحديثات المحددة التي استلمها كل برج؛ فتسجيل عدة عناوين لا يثبت وحده تكرار جميع الحالات. تقلل الأجهزة والشبكات والمواقع المنفصلة الأعطال المشتركة. تحد ملفات blob المشفرة والاتصالات الموثقة من انكشاف الأرصدة، لكنها لا تزيل البيانات الوصفية أو انكشاف وتيرة التحديثات أو خطر الربط بينها. [5] [8]

عند التحقق، ميّز بين تحديث أُرسل وتحديث استُلم فعلًا. الأوامر والحقول التالية مرجع أكثر تفصيلًا لمسؤولي LND؛ فإقرار البرج باستلام النسخة ليس تأكيدًا لمعاملة في كتلة. استخدم lncli wtclient towers وlncli wtclient tower وlncli wtclient stats وlncli wtclient policy. في LND ⁦v0.21.3-beta⁩ ميز بين num_backups وnum_pending_backups؛ فالحقل الثاني يعد النسخ التي تنتظر إقرار البرج باستلامها. ويعد num_failed_backups في استجابة stats النسخ الفاشلة التي لم يتأكد استلامها. تغطي الإحصاءات الفترة منذ بدء العميل. يشير active_session_candidate إلى مرشح لإنشاء جلسات التخزين، وليس دليلًا على حماية كاملة. [6]

الإعداد الصحيح هو البداية. ينبغي أن يشمل الاختبار المسار كاملًا من اكتشاف حالة ملغاة إلى استرجاع الأموال المحمية؛ لا تنفذ هذه التجربة بأموالك الحقيقية. افحص إصدارات العميل والبرج المحددة، وأنواع القنوات وsession المدعومة، وحداثة البيانات، والرسوم، والتزامن مع السلسلة. اختبر وظيفة الاستجابة في بيئة اختبار معزولة؛ فعملية إغلاق عادية من طرف واحد (force close) لا تثبت الاستجابة لحالة ملغاة. يتمثل دليل النتيجة في نشر الحالة الملغاة (breach) وjustice transaction المعاد بناؤها ومخرجاتها المؤكدة. لا يضمن العرض الناجح التوفر مستقبلًا ولا يزيل جميع مخاطر Lightning. [1] [3] [6]