بيتكوين كور يدرس إلغاء دعم التوجيه المشفر مع تدهور صحة العقد وتعرض المستخدمين لهجمات الحجب المعزول
يسعى مطورو Bitcoin Core حاليًا إلى تقييم ما إذا كانت شبكة النقل الثانوية CJDNS تُعدّ ضمانًا قيّمًا أم عبئًا مكلفًا يستحق الإزالة.
أرقام الاستخدام تثير التساؤلات
في مناقشة مفتوحة حول دعم CJDNS، أفاد عضو فريق Bitcoin Core أندرو تشاو أن قاعدة بيانات أحد خوادم البذور (seeders) احتوت على 25 عنوانًا لـ CJDNS، وتمكنت من الوصول إلى 22 عنوانًا، لكنها صنّفت سبعة فقط على أنها “جيدة”. كما أبلغ كاتب المشكلة مارتن زومساندي عن رؤيته لثلاثة أو أربعة أقران فقط (peers) بالرغم من أن Bitcoin Core يأتي مع 11 بذرة CJDNS ثابتة.
دفعت هذه الأرقام بعض المطورين إلى دعم فكرة إيقاف الدعم تدريجيًا، مع اقتراح أن يقوم Bitcoin Core بتحذير المستخدمين في إصدار 32.x قبل التخطيط للإزالة الكاملة في إصدار 33.x. لكن هذا التسلسل الزمني ما زال مطروحًا كنقاش مفتوح حتى الآن في إصدار 32.0، دون وجود تنفيذ عملي أو طلب سحب (pull request) مخصص لذلك.
ما هي CJDNS تحديدًا؟
تعمل CJDNS كخيار اختياري لنقل البيانات ومعالجة العناوين في Bitcoin Core، خارج نظام الإجماع (consensus) الخاص بالبيتكوين. السؤال المطروح هو: هل يجب الإبقاء على دعم عناوين CJDNS كخيار احتياطي، خاصةً مع سهولة استهداف العقد المعتمدة عليها حصريًا نظرًا لقلة عدد الأقران المتاحين؟
معايير “العقد الجيدة” صارمة
أرقام البذور المذكورة تصف قاعدة بيانات واحدة في نقطة زمنية محددة، وقد يكون عدد مستخدمي CJDNS عالميًا أكبر من ذلك. يطبّق خادم البذور معيار “جيد” كفلتر تقني صارم يتجاوز مجرد إمكانية الوصول. يجب أن تجتاز العقدة فحوصات تغطي المنفذ، والخدمات المعلنة، وإصدار البروتوكول، وارتفاع السلسلة، وموثوقية التشغيل المستمر. هذا يفسر كيف يمكن الوصول إلى 22 عنوانًا بينما سبعة فقط تُصنف “جيدة”.
مع بقاء سبعة عقد جيدة فقط من أصل 22 تم الوصول إليها، يصبح مجمع الأقران المتاح ضحلًا جدًا. اقترح زومساندي أن الرقم المنخفض بالمئات (مثل 100-200) قد يكون مستوى معقولًا يبرر استمرار الدعم، وهذا المعيار الشخصي يمنح المطورين رقمًا محددًا للنقاش بدلاً من مجرد شكوى عامة حول قلة الاستخدام.
خطر “الاحتجاب” (Eclipse Attack) غير محسوم
حسابات عدد الأقران وحدها لا تكشف التكلفة الحقيقية لشن هجوم احتجاب. يحافظ Bitcoin Core عادةً على ثماني اتصالات صادرة كاملة لنقل البيانات واتصالين إضافيين لنقل الكتل فقط. أشار أحد المساهمين إلى ضرورة ربط أي معيار لاستمرار CJDNS بتكلفة ملء تلك الفتحات العادية واحتجاب عقدة تعتمد على CJDNS فقط.
هجوم الاحتجاب يعزل العقدة عن الشبكة عبر التحكم في الأقران التي تشكل رؤيتها. في شبكة نقل بقائمة عناوين صغيرة معروفة، يكون الهدف أكثر تركيزًا للهجوم. التوثيق الحالي لـ Bitcoin Core يحذر بالفعل من التشغيل المعتمد على CJDNS فقط لأن العقدة قد تفشل في ملء اتصالاتها الصادرة، وتكرر المحاولة مع العناوين القليلة المعروفة، مما يجعلها أكثر عرضة لهجمات Sybil.
نجاح الاحتجاب يعتمد على أكثر من عشر فتحات اتصال صادرة. النقاش العام يترك التكلفة الكاملة للهجوم غير محسوبة. توفر العناوين، واختيارها، ومعايير موثوقية الزاحف، والاتصالات الإضافية العرضية، كلها عوامل تؤثر على التعرض الفعلي. المجمع المقاس يدعم القلق بشأن التركيز للعقد المعتمدة على CJDNS فقط، لكن تكلفة استغلال ذلك تبقى غير معلومة.
قيمة التكرار تعتمد على طريقة الاستخدام
تقدم CJDNS قيمة مختلفة عندما تكون مسارًا واحدًا من بين عدة مسارات. توثيق Bitcoin Core يعرضها كخيار تكميلي إلى جانب IPv4 و IPv6 و Tor و I2P، مما يسمح للعقدة بالاحتفاظ بمسار آخر متاح في حال حدوث مشاكل في شبكة معينة.
أصبح استخدام هذا الخيار أسهل. إصدار CJDNS 22.1 في 8 يناير 2025 قدّم خاصية الربط التلقائي عبر البذور (DNS-seeded auto-peering)، مما جعل الإضافة اليدوية للأقران اختيارية. ثم دمج Bitcoin Core توثيقًا محدثًا في 30 مارس 2026 يحل محل التعليمات القديمة، وأُضيف توثيق آخر في 18 أغسطس 2026 يثبط صراحةً الاستخدام المعتمد على CJDNS فقط لأن مجمع العناوين صغير جدًا.
المصالح المختلفة للمشغلين
يواجه مشغلو CJDNS فقط والمشغلون متعددو الشبكات مخاطر مختلفة. مشغل CJDNS فقط يواجه خطر المجمع الضحل الذي يحذر منه التوثيق حاليًا. مشغل الشبكة المختلطة يستخدم CJDNS لتنويع المسارات ويحتفظ بمسارات تلقائية أخرى حتى عندما يكون أقران CJDNS قليلين.
إيقاف الدعم مستقبلًا سيزيل إعدادات النقل مع ترك قواعد صحة الكتل دون تغيير. Bitcoin Core أضاف دعم CJDNS الكامل في الإصدار 23.0 كميزة شبكة P2P. النقاش محصور في معالجة العناوين وخيارات الاتصال؛ قواعد الإجماع وصحة الكتل خارج نطاقه.
المتأثرون المباشرون هم المستخدمون الذين يحددون الخيار -cjdnsreachable (الذي يوجه Bitcoin Core لمعاملة نطاق IPv6 المعني على أنه CJDNS) أو -onlynet=cjdns (الذي يقتصر الاتصالات الصادرة التلقائية على CJDNS). هذا الخيار يمكن دمجه حاليًا مع شبكات أخرى، بينما تبقى الاتصالات الواردة والمضافة يدويًا متاحة وفقًا للتوثيق.
الوضع الحالي والقرار المفتوح
بقي مشروع #36041 مفتوحًا، مع تسجيل تسلسل التحذير والإزالة فقط كاقتراح. يُظهر مجمع أقران صغيرًا ملحوظًا، ودعمًا متعددًا لفكرة الإيقاف التدريجي، وتسلسل إصدارات مقترحًا. كما يكشف لماذا يعدّ عدد الاستخدامات وحده اختبارًا غير مكتمل: القدرة الاحتياطية تكون أكثر قيمة قبل فشل المسار الأساسي، لكن شبكة احتياطية تفشل في ملء اتصالاتها قد توفر مرونة أقل مما يوحي به وجودها في الكود.
Bitcoin Core ما زال يدعم CJDNS حاليًا. أي طلب سحب للتحذير أو الإزالة سيغير وضع النقاش. وجود سبع عقد جيدة يجعل مقايضة تنوع الشبكات قابلة للقياس ويترك خيار الإزالة مفتوحًا.
الأسئلة الشائعة
هل سيزيل Bitcoin Core دعم CJDNS قريبًا؟
لا يوجد قرار نهائي بعد. النقاش ما زال مفتوحًا، ويوجد اقتراح بالتحذير أولاً في إصدار 32.x ثم الإزالة في 33.x، لكن لم يتم دمج أي تغييرات في الكود حتى الآن.
ما سبب قلق المطورين بشأن CJDNS؟
القلق الرئيسي هو قلة الاستخدام الفعلي (فقط 7 عقد “جيدة” في قاعدة بيانات البذور)، مما يجعل العقد المعتمدة على CJDNS فقط أسهل استهدافًا بهجمات الاحتجاب (Eclipse) التي تعزلها عن الشبكة.
هل ما زال بإمكاني استخدام CJDNS مع Bitcoin Core؟
نعم، الدعم ما زال متاحًا بالكامل. يُنصح بعدم الاعتماد على CJDNS فقط، بل استخدامه كمسار إضافي مع IPv4 أو IPv6 أو Tor أو I2P لضمان اتصال أكثر استقرارًا وأمانًا.
