إصدار Bitcoin Core v32.0rc1 يُدخل تغييرات على بروتوكولات المحفظة وقد يسبب اضطرابات للتطبيقات

حوّل إصدار Bitcoin Core v32.0rc1 الفترة الممتدة من 14 سبتمبر إلى 10 أكتوبر إلى اختبار توافق مكثّف لمشغلي العُقد ومزوّدي المحافظ والخدمات التي تعتمد على واجهات RPC في Bitcoin Core. جرى وسم نسخة المرشح RC بتوقيع مُتحقَّق منه في 14 سبتمبر، بينما تشير الجدولة الحالية إلى 10 أكتوبر كموعد مستهدف لوضع الوسم النهائي v32.0، ما يعني نافذة اختبار تمتد 26 يومًا. وكانت معاينة CryptoSlate في أغسطس قد رصدت هدفًا سابقًا لـ RC1 بتاريخ 10 سبتمبر، في حين تُظهر الجدولة الآن 14 سبتمبر، بفارق أربعة أيام من دون ما يثبت أن الموعد النهائي الأصلي فاته إصدار غير متغيّر. وسم v32.0rc1 يدل على برمجيات ما قبل الإصدار، وليس ترقية نهائية للإنتاج، كما أنه لا يعني تفعيل قواعد إجماع جديدة. أحد التغييرات المرتبطة بمسودة BIP 323 يعدّل كيفية تعامل Bitcoin Core مع بتّات الإشارة وتحذيرات "النشر غير المعروف"، مع بقاء المقترح في حالة "Draft". يمكن للمشغلين البدء وفق نمط الاختبار عالي المستوى الوارد في أحدث دليل لاختبارات إصدارات RC من Bitcoin Core: تشغيل الميزات الأكثر استخدامًا داخل أدلة بيانات مؤقتة منفصلة، ثم مقارنة نسخة المرشح مع الإصدار السابق. صفحة التنزيل الرسمية تُدرج 31.1 باعتباره خط الأساس الحالي. تساعد هذه المقارنة على كشف فروقات في بدء تشغيل العُقد، وسلوك المحافظ، واستجابات RPC من دون التعامل مع RC كأنه تحديث إنتاج اعتيادي. أبرز تغيير للأداء في مسودة ملاحظات إصدار v32 يتمثل في الجلب المسبق المتوازي لمخرجات المعاملات أثناء ربط الكتل. الإعداد الافتراضي يحدد ثمانية عمال، ويدعم حتى 16، مع إمكانية تعطيله. اختبار التحقق المعتمد على القرص وفق إعدادات متعددة يوضح ما إذا كانت سرعة معالجة الكتل تأتي على حساب غير مقبول في استهلاك CPU أو الذاكرة أو زمن استجابة التخزين على عتاد المشغّل. على صعيد المحافظ والتكاملات الخدمية، تبرز مخاطر انكسار منفصلة. أربع واجهات RPC ستتحول افتراضيًا إلى PSBTv2، بينما تُزيل واجهات أخرى حقولًا مُهملة أو ترفض وسيطات كانت الإصدارات الأقدم تتسامح معها. لذلك يُستحسن أن تراجع الفرق التي تُنشئ أو تُحوّل أو تُجري feebump لملفات PSBT تدفق هذه المعاملات عبر محلّلاتها وموقّعاتها اللاحقة. اختبار مسارات الفشل المتعلقة بالرسوم مهم أيضًا. المسار الافتراضي في estimatesmartfee يجمع بين مُقدّر blockpolicy ومُقدّر mempool، وقد يُرجع تقديرًا أدنى، وقد يُطلق خطأً إذا فشل أي من المكوّنين. يُنصح بمراقبة سلوك الإقلاع، وحالات mempool الشحيحة أو غير الصحية، ثم التأكد من أن المراقبة وآليات الرجوع الصريحة إلى blockpolicy تعمل كما هو متوقع. إعادة كتابة خادم HTTP توسّع نطاق الاختبارات إلى ما يتجاوز العُقدة نفسها. تتضمن التغييرات حدًا لحجم الترويسات يبلغ 8,192 بايت، وتشديد التعامل مع الترويسات غير السليمة، وسقفًا افتراضيًا يبلغ 16 اتصال RPC، وضوابط تخزين مؤقت جديدة لـ REST، وقطع الاتصال فورًا عن عناوين العملاء غير المصرح لها. قد تظهر آثار هذه التغييرات في الموجّهات العكسية (reverse proxies) وفحوصات السلامة (health checks) ومجموعات العملاء ومعالجات الأخطاء. الرجوع للإصدار السابق يستحق الاهتمام بالقدر نفسه. إعادة بناء فهرس المعاملات أصبحت تستهلك أقل من نصف مساحة القرص، لكن الإصدارات الأقدم لا تستطيع قراءة الصيغة الجديدة، ما يعني أن التخفيض (downgrade) قد يطلق إعادة بناء أخرى قد تستغرق ساعات. أما المشغلون الأكثر حساسية للخصوصية، فعليهم إعادة إنتاج مسارات فشل البث الخاص حول إصلاح Tor الاحتياطي، وطابور 10,000 إدخال، وحد 1,000 محاولة، وسلوك الترحيل تحت الضغط. ومع بقاء الوسم النهائي هدفًا لا أكثر، تصبح هذه الحالات الطرفية هي جوهر العمل العملي خلال نافذة اختبار RC.