Bitcoin Core 32 يقترب من الإطلاق النهائي مع تحسينات في الرسوم وأداء العقد
تدخل عملية تطوير النسخة الجديدة من برنامج Bitcoin Core مراحلها الأخيرة، مع وصول الإصدار 32.0 إلى مرحلة الاختبارات النهائية قبل الإطلاق، بعدما طرح المطورون النسخة المرشحة للإصدار v32.0rc1 في 14 سبتمبر، تمهيداً لإصدار النسخة المستقرة المتوقع في 10 أكتوبر، ما لم تستدعي نتائج الاختبارات إدخال تعديلات على الجدول الزمني.
وبحسب صفحة الإصدار الرسمية للمشروع على GitHub، تحمل النسخة التجريبية رقم الالتزام d0231bb، وتم توقيعها بشكل موثّق من أحد مسؤولي صيانة المشروع في 14 سبتمبر عند الساعة 12:58 بالتوقيت العالمي.
ويأتي إصدار النسخة المرشحة بعد دخول المشروع مرحلة تجميد الميزات في 20 أغسطس، حيث أصبحت التغييرات اللاحقة تقتصر أساساً على الإصلاحات الضرورية استعداداً للإطلاق. وفي 14 سبتمبر، جرى فصل فرع 32.x عن فرع التطوير الرئيسي، لبدء دورة الاختبارات النهائية، بالتوازي مع مواصلة تطوير النسخة التالية Bitcoin Core 33 بشكل مستقل.
وتتيح مرحلة الإصدار المرشح لمشغلي العقد ومطوري المحافظ وغيرهم اختبار البرنامج في ظروف مختلفة، قبل اتخاذ القرار النهائي بشأن إطلاق النسخة المستقرة. كما فتح المشروع في 15 سبتمبر موضوعاً مخصصاً لجمع نتائج الاختبارات والملاحظات المتعلقة بـ 32.0rc1، داعياً المختبرين إلى اتباع دليل الاختبار والإبلاغ عن أي مشكلات عبر قضايا منفصلة على GitHub.
ولا تتضمن ملاحظات الإصدار الحالية تغييرات على قواعد إجماع بيتكوين، وبالتالي لا يعيد التحديث تحديد المعاملات أو الكتل التي تعتبرها الشبكة صالحة.
وتركز التعديلات بدلاً من ذلك على مجموعة من الجوانب التقنية، من بينها أداء العقد، وواجهات المحافظ، وتقدير الرسوم، والشبكات، وتحسين الأداء العام، إلى جانب إصلاحات مرتبطة بالأمان.
من أبرز التغييرات في Bitcoin Core 32 إعادة تطوير آلية تقدير رسوم المعاملات من خلال تعديل وظيفة estimatesmartfee، وهي واجهة RPC تعتمد عليها المحافظ والتطبيقات لتحديد الرسوم المناسبة عند إرسال معاملات بيتكوين.
وكان نظام التقدير يعتمد بصورة أساسية على بيانات المعاملات التي جرى تأكيدها في الكتل السابقة، لكن الإصدار الجديد يضيف آلية منفصلة تستند إلى المعاملات الموجودة حالياً في ذاكرة المعاملات المؤقتة (mempool) لدى العقدة.
ويتيح هذا النهج الاستفادة من ظروف الشبكة في الوقت الفعلي، بما يسمح بإنتاج تقديرات اقتصادية ومحافظة للرسوم بناءً على مستوى المنافسة الحالي على مساحة الكتل.
وقبل استخدام بيانات الـmempool، يتحقق Bitcoin Core من نشاط الكتل الأخيرة، كما يستطيع رفض التقدير إذا كانت ذاكرة المعاملات تبدو فارغة بصورة غير طبيعية أو غير مستقرة.
وفي حال تمكن النظامان من إنتاج تقديرات صالحة، تعتمد estimatesmartfee التقدير الأقل للرسوم في الوضع الافتراضي المشترك. وبذلك لا تهدف آلية الـmempool الجديدة إلى رفع توصية الرسوم، وإنما يمكنها خفضها عندما تشير المعاملات المعلقة إلى أن المنافسة على إدراج معاملات جديدة في الكتل أصبحت أقل.
وقد يساعد ذلك في جعل تقديرات الرسوم أكثر سرعة في الاستجابة بعد انحسار فترات ازدحام الشبكة، إذ قد تظل البيانات المستخلصة من الكتل السابقة متأثرة بفترة شهدت رسوماً مرتفعة، بينما تكشف حالة الـmempool الحالية عن انخفاض عدد المعاملات التي تنتظر التأكيد.
كما يتيح الإصدار للمطورين اختيار طريقة تقدير الرسوم المستخدمة عبر خيار fee_rate_estimator، الذي يوفر ثلاثة أوضاع تشمل block_policy وmempool_policy، إلى جانب الوضع الافتراضي المشترك.
ويحتفظ Bitcoin Core بإحصاءات آلية تقدير الرسوم القائمة على الـmempool في ملف بيانات منفصل، ما يسمح بإعادة تحميل هذه المعلومات عند إعادة تشغيل العقدة.
كما ستستخدم المحافظ نظام التقدير المشترك بصورة افتراضية، مع إمكانية معرفة النظام الذي أنتج تقدير الرسوم، بينما توفر مستويات التفصيل الأعلى بيانات إضافية حول حالة الـmempool للتطبيقات التي تحتاج إلى معلومات أكثر دقة.
يحمل الإصدار الجديد أيضاً تحسينات على أداء العقد أثناء عملية التحقق من الكتل، خصوصاً في الحالات التي تحتاج فيها البيانات المطلوبة إلى الاسترجاع من وحدات التخزين.
ويتيح Bitcoin Core 32 تنفيذ قراءة مسبقة متوازية (prefetch) لمخرجات المعاملات السابقة، المعروفة باسم prevouts، من قاعدة بيانات chainstate باستخدام عدة خيوط معالجة بالتوازي مع استمرار عملية التحقق من الكتل.
ويأتي الإعداد الافتراضي للقراءة المسبقة عند 8 خيوط، مع إمكانية رفع العدد إلى 16 خيطاً أو تعطيل القراءة المتوازية بالكامل من خلال ضبط القيمة على صفر.
وتعد بيانات prevouts عنصراً أساسياً في عملية التحقق، لأنها تحدد العملات التي يجري إنفاقها بواسطة مدخلات المعاملات. وتحتاج العقدة إلى هذه البيانات للتأكد من وجود المدخلات، وعدم إنفاقها في وقت سابق، وتوافق المعاملات مع قواعد التحقق المعمول بها.
ويستهدف هذا التعديل تقليص الوقت الذي تقضيه العقد في انتظار عمليات القراءة من القرص، خصوصاً عند التعامل مع كتل تحتوي على عدد كبير من المدخلات التي تتطلب الوصول إلى بيانات غير موجودة مسبقاً في الذاكرة.
ورغم اقتراب موعد الإصدار النهائي، فإن تشغيل Bitcoin Core لا يعني انتقال جميع العقد إلى النسخة الجديدة تلقائياً. فعملية تحديث البرنامج تظل مرتبطة بقرار مشغلي العقد أنفسهم، الذين يختارون توقيت تثبيت الإصدارات الجديدة، ما يسمح للإصدارات الأقدم بالاستمرار في العمل حتى بعد توفر تحديثات أحدث.
ويكتسب هذا الجانب أهمية خاصة في ما يتعلق بالإفصاحات الأمنية، إذ سبق لمشروع Bitcoin Core أن كشف في مايو عن الثغرة CVE-2024-52911 بعد انتهاء دورة دعم فرع 28.x، رغم أن الخلل كان قد جرى إصلاحه مسبقاً في الإصدار Bitcoin Core 29.0 قبل نشر التفاصيل التقنية المتعلقة به.
وبحلول 16 سبتمبر، لم تكن النسخة النهائية v32.0 قد صدرت بعد، بينما لا يزال الجدول المستهدف يشير إلى 10 أكتوبر موعداً للإطلاق، مع بقاء إمكانية تعديل الموعد قائمة وفقاً لنتائج الاختبارات وما قد يظهر خلالها من مشكلات تحتاج إلى إصلاح قبل طرح النسخة المستقرة.
