BIP324

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

تتفق عقدتان تدعمان البروتوكول على مفاتيح عند الاتصال، ثم تتواصلان بالتشفير. لا تحتاجان إلى معرفة هوية بعضهما مسبقًا ولا إلى شهادة من جهة مركزية. ولهذا تحديدًا لا يعني «مشفّر» أنه موثوق. فالعقدة المقابلة تقرأ الرسائل بالطبع، وقد تكون مملوكة لمهاجم. [1]

عند بدء الاتصال، خلال التهيئة المعروفة باسم handshake، تُنشئ العقدتان مفاتيح مؤقتة. المفتاح الخاص قيمة عددية سرية، أما المفتاح العام المقابل فيمكن مشاركته مع الآخرين. وباستخدام ECDH، تحسب كل منهما السر المشترك نفسه من دون تبادل المفاتيح الخاصة. ومن هذا السر تُشتق مفاتيح حماية النقل. أما ElligatorSwift فهي طريقة لتمثيل المفاتيح العامة تجعل هذا الجزء من التبادل شبيهاً ببيانات عشوائية، فيصعب تمييزه بنمط ثابت. هذه مفاتيح خاصة باتصال الشبكة فقط؛ ليست المفاتيح الخاصة التي تتيح إنفاق بيتكوين، ولا seed، أي القيمة السرية الأولية التي تُشتق منها مفاتيح المحفظة. تفعيل النقل المشفر لا يتطلب مشاركة نسخة المحفظة الاحتياطية مع أي شخص. [1] [8]

تخيّل أن شخصاً اعترض رسالة في الطريق وغيّر محتواها. يستخدم BIP324 خوارزمية ChaCha20Poly1305، وهي تجمع التشفير مع التحقق من أن الرسالة تتوافق مع مفتاح الاتصال ولم تُعدّل. لا يستطيع مهاجم لا يملك المفتاح أن يغيّر البيانات ببساطة ويُنتج رسالة صالحة. لكن هذا التحقق لا يثبت أنك تشارك المفتاح مع العقدة المقصودة. يستطيع وسيط نشط، أثناء إنشاء الاتصالات، أن يظهر لكل جانب وكأنه الطرف الآخر. عندئذ يملك اتصالين مشفرين منفصلين ويقرأ الرسائل وينقلها بينهما. لذلك تبقى حماية الرسائل والتحقق من الطرف المقابل مهمتين مختلفتين. [1]

تتجدد المفاتيح أثناء الاتصال. ومع محو الأسرار القديمة بطريقة سليمة، لا يكشف الحصول لاحقًا على المفاتيح الحالية تلقائيًا كامل التسجيل السابق. تسمى هذه الخاصية forward secrecy. لكنها لا تحمي الرسائل التي قرأتها العقدة الأخرى أو حفظتها بالفعل. ولا تفيد ضد مهاجم يحتفظ بالسيطرة على الحاسوب؛ كما قد تظل أحدث مجموعة من الرسائل قابلة للكشف. [1]

يبقى v1 transport مدعومًا للتوافق. وإذا فشل اتصال v2 فقد يحاول البرنامج استخدام v1. لذلك يستطيع مهاجم نشط حجب الاتصالات المشفّرة ومحاولة فرض العودة إلى اتصال غير مشفّر. يزيد BIP324 كلفة المراقبة السلبية، لكنه لا يضمن مقاومة عامة لهجوم downgrade ولا توافر الاتصال. [1] [4]

لا يخفي BIP324 عنوان IP ولا جميع أنماط توقيت الحركة وحجمها. عنوان IP هو عنوان الشبكة الذي يستخدمه الجهاز للتواصل عبر الإنترنت. قد يعالج Tor جزءًا آخر من المشكلة، لكن الجمع بينهما لا يمنح إخفاء الهوية تلقائيًا. ومهما كان مسار الرسالة، يجب على Full Node التحقق من المعاملات والتوقيعات والكتل. التشفير وحده لا يعالج Eclipse Attack الذي يحيط فيه المهاجمون بالعقدة. [1] [6]

أضاف Bitcoin Core 26.0 دعم v2 في 2023، وكان معطّلًا افتراضيًا في البداية. ثم فعّلته النسخة 27.0 افتراضيًا. لذلك تشير سنة هذا المدخل إلى أول دعم في Bitcoin Core، لا إلى نشأة المقترح. يجري التفاوض لكل اتصال على حدة؛ ودعم البرنامج لا يعني أن جميع الأطراف peers المتصلة تستخدم v2. [3] [4]

يمكن لمشغّل Bitcoin Core قراءة حالة الاتصالات بالأمر bitcoin-cli getpeerinfo. هذا استعلام عبر RPC، وهي واجهة للتحكم بالعقدة وقراءة معلوماتها؛ هذا الأمر لا يبث معاملات إلى شبكة Bitcoin ولا يغيّر الإعدادات. تعرض النتيجة كل اتصال على حدة. في الحقل transport_protocol_type، تعني v2 نقلاً مشفراً، وv1 النقل القديم غير المشفر، وdetecting أن الاختيار لم يُحسم بعد. يحتوي session_id على معرّف اتصال v2، ويكون فارغاً فيما عدا ذلك. وجود المعرّف وحده لا يتحقق من الطرف المقابل. يمكن لمشغّلين مقارنة معرّف اتصالهما المتبادل عبر قناة موثوقة أخرى لكشف وسيط؛ الاتصالات المعتادة لا تُجري هذا التحقق تلقائياً. تصف النتيجة هذه الوصلة، لا المسار الكامل للمعاملة عبر الشبكة. كما يتضمن المخرج معلومات شبكية لا حاجة إلى نشرها. [5] [1]

يسرد BIP324 المؤلفين Dhruv Mehta وTim Ruffing وJonas Schnelli وPieter Wuille. خُصص الرقم في 2019؛ وعند المراجعة في 17 أكتوبر 2026 كانت الحالة Deployed. لا يتطلب اعتماده Soft Fork أو تغيير عرض البيتكوين. إنه تحسين تدريجي لاتصالات العُقد، تتوقف فائدته على صحة التنفيذ والاتصالات المستخدمة فعليًا. [1]