Christian Decker باحث ومطور في Bitcoin وLightning، وهي شبكة للمدفوعات عبر قنوات دفع. شارك في دراسة انتشار البيانات وفي eltoo وBIP 118 وGreenlight. ويمكن فهم إسهاماته من خلال المشكلات التي يعالجها: اختلاف المعلومات داخل الشبكة، واتفاقات الرصيد القديمة، ومتطلبات تشغيل عقدة خاصة.
عند البحث عن أعمال Decker يظهر حساب cdecker واسم Snyke. وعند المراجعة في أكتوبر 2026 كان ملفه العام يذكر Blockstream أيضًا. يساعد ذلك على ربط المؤلف بالكود والمقترحات، لكن نبذة قصيرة لا تثبت وحدها مسماه الوظيفي الحالي. في شبكة مفتوحة، تُقاس قيمة المقترح بالمشكلة التي يحلها وبقدرته على اجتياز المراجعة. لا يمنح اسم صاحبه أو جهة عمله سلطة تغيير قواعد الجميع. [1]
تنتشر الكتلة الجديدة تدريجيًا: يرسلها حاسوب إلى غيره، ويستغرق النقل وقتًا. قاس Christian Decker وRoger Wattenhofer ذلك في دراسة عام 2013. بحثا انتشار المعاملات والكتل وعلاقة التأخير بالتفرعات المؤقتة، حين تعمل أجزاء الشبكة اعتمادًا على كتل جديدة مختلفة. توضح هذه القياسات التاريخية سلوك الشبكة عمليًا، لكنها لا تصف سرعة Bitcoin اليوم؛ فقد تغيرت البرامج وطرق نقل البيانات منذ ذلك الحين. [2]
في قناة الدفع يجدد المشاركون اتفاقهم بشأن نصيب كل منهم من الأموال المقيدة معًا. ماذا لو أغلق أحدهم القناة باتفاق قديم يصب في مصلحته؟ يتيح مقترح eltoo الذي وضعه Decker وRusty Russell وOlaoluwa Osuntokun فرض حالة أحدث قبل التسوية النهائية. تخيل استبدال كشف حساب قديم بآخر اتفاق معتمد. هذه آلية مقترحة، وليست ميزة موجودة تلقائيًا في كل قناة Lightning مستخدمة اليوم. [3]
إمكانية التصحيح وحدها لا تكفي. في eltoo يجب تأكيد معاملة التصحيح قبل أن تصبح تسوية الحالة القديمة ممكنة. تمنح قاعدة OP_CSV مهلة للرد: لا تسمح بإنفاق معين إلا بعد مدة انتظار محددة تبدأ من تأكيد المخرج المعني. لذلك يجب أن يراقب السلسلةَ المستخدمُ أو خدمة يفوضها. يغير المقترح طريقة التعامل مع الحالات القديمة، لكنه لا يجعل البقاء دون اتصال لمدة غير محدودة آمنًا. [3]
يتطلب تطبيق اتفاق أحدث على حالات قديمة مختلفة قواعد توقيع مناسبة. يقترح BIP 118 الذي كتبه Decker وAnthony Towns آلية SIGHASH_ANYPREVOUT. عند المراجعة في أكتوبر 2026 كانت حالة الوثيقة Draft، أي مسودة. وهي تصف تغييرًا في الإجماع عبر soft fork: تعديل القواعد التي تتحقق العقد بموجبها من Bitcoin. نشر الوثيقة أو دعم المطورين ليس دليلًا على التفعيل. الاقتراح والتنفيذ وتبني الشبكة مراحل منفصلة. [4]
عادة يرتبط التوقيع أيضًا بمخرج المعاملة السابق الذي يُنفق، أي مبلغ له شروط إنفاق. يخفف BIP 118 هذا الارتباط في نمط محدد، فيمكن ربط المعاملة الموقعة بمخرج آخر متوافق. يساعد ذلك على استبدال حالات القناة القديمة، ولا يتيح إنفاق أموال الآخرين عشوائيًا. لكن اتساع إمكانية إعادة استخدام التوقيع يحتاج إلى تصميم دقيق. وبحسب النمط المختار، تظل للارتباط بالمبلغ وشروط الإنفاق أهمية أيضًا. [4]
تشغيل عقدة Lightning يتطلب متابعة مستمرة. أعلنت Blockstream الإطلاق العام لخدمة Greenlight في 12 أكتوبر 2023، وقدمت Decker بصفته قائد المشروع. تتوزع المهام: يحتفظ المستخدم بالمفاتيح الخاصة، ويتولى مزود الخدمة تشغيل البنية التحتية للعقدة. المفتاح الخاص يجيز الإنفاق، لذا فحيازته ليست هي تشغيل خادم. لا يضمن هذا النموذج وحده خدمة بلا انقطاع أو شروطًا تجارية لا تتغير. ينبغي تقييم هذين الجانبين بصورة مستقلة. [5]
Core Lightning برنامج لتشغيل عقدة Lightning. توسع الإضافات وظائفه بحسب حاجة المشغل، ويساعد reckless على تثبيتها وتفعيلها. هذا نوع مختلف من التغيير عن اقتراح قواعد توقيع جديدة في Bitcoin. تثبيت إضافة لا يُدخل BIP 118 تلقائيًا في قواعد الشبكة كلها. تربط أعمال Decker بين البحث ومقترحات البروتوكول والأدوات العملية، لكن لكل مجال طريقه من الفكرة إلى الاستخدام الفعلي. [6]
للحصول على صورة أوضح، اقرأ هذا المدخل مع Elizabeth Stark, Andreas Antonopoulos, Lightning Network. تشير إلى هذا المدخل أيضًا Elizabeth Stark, Andreas Antonopoulos.