أعلنت شبكة R3E Network عن إطلاق الإصدار المستقر الأول من عميل Neo X المبني على لغة Rust، والذي يحمل اسم neox-rs. هذا الإصدار ينقل العميل من مرحلة الاختبارات الأولية إلى مرحلة الإنتاج الكامل كعقدة كاملة مؤهلة. الإصدار الجديد v2.4.3 يتضمن إصلاحات لأربعة اختلافات في الإجماع (Consensus) مقارنة بالعميل المرجعي، وقد تحقق من صحة أكثر من 7.21 مليون كتلة على الشبكة الرئيسية (MainNet) دون أي أخطاء في جذور الحالة (State-root mismatches).
هذا الإصدار يأتي بعد تغطية الإصدار التجريبي rc.5، الذي قدم neox-rs كأول عميل بديل لـ Neo X مبني على إطار عمل Paradigm’s Reth.
الإصدار التجريبي النهائي والتحقق على شبكة الاختبار (TestNet)
الإصدار 2.4.1-rc.6 الذي صدر في 23 يوليو أتم عملية التحقق الكاملة على شبكة الاختبار، حيث نفذ جميع الكتل البالغ عددها 9,167,856 كتلة بعد كتلة التأسيس (post-genesis) و317,350 معاملة دون أي خطأ. هذا الإصدار قدم أيضاً ميزات جديدة مثل اللحاق المحدود (bounded catch-up)، وتقوية آلية DKG، بالإضافة إلى علامة إلزامية --validator.experimental لتشغيل المدقق على الشبكات العامة، مما يحدد الفرق بين وضع المدقق والوضع العادي.
أول إصدار مستقر
الإصدار 2.4.1 الذي صدر في 24 يوليو رفع الإصدار rc.6 إلى حالة مستقر، ليكون أول إصدار غير تجريبي للمشروع. هذا الإصدار أعاد تنفيذ جميع كتل الشبكة الرئيسية البالغ عددها 7,195,922 كتلة، منتجاً جذور حالة متطابقة لكل كتلة ومطابقاً للإيصالات (receipts) لجميع المعاملات البالغ عددها 368,040 معاملة. كما يتضمن سكريبت تحقق تفاضلي قابل للتكرار neox-full-differential.py يمكن المشغلين المستقلين من التحقق من التطابق بين Rust وGo عبر كل كتلة ومعاملة وإيصال.
هذا الإصدار طور أيضاً قاعدة Reth الأساسية من commite3823342 إلى 32de8f9c، وعزز معالجة تخزين المدقق، وحسن إعادة تشغيل DKG الأساسي. لكن التحول بين جولات DKG لم يتحقق بعد في الاختبارات المختلطة بين العملاء.
إصلاح اختلافات الإجماع (Consensus)
الإصدار 2.4.2 الذي صدر في 25 يوليو عالج أربعة اختلافات في الإجماع تم اكتشافها من خلال الاختبارات التفاضلية بين العملاء. ونُصح كل من يشغل الإصدار v2.4.1 بالترقية فوراً.
الإصلاح الأهم صحح طريقة معالجة neox-rs لإعادة بناء المغلفات المضادة للـ MEV (Anti-MEV Envelope). نظام Anti-MEV في Neo X يقوم بتشفير المعاملات داخل مغلفات باستخدام التشفير العتبي (threshold encryption) قبل ترتيبها في الكتلة. أثناء إعادة البناء، العميل المرجعي يتخطى بعض المغلفات ويتركها مشفرة. لكن neox-rs كان يتتبع مواضع المغلفات بمؤشر مختلف، مما أدى إلى فك تشفير مغلفات يتخطاها العميل المرجعي، منتجاً قائمة معاملات مختلفة وربما انحرافاً عن السلسلة الأساسية. الإصلاح جعل تتبع المؤشر في neox-rs متوافقاً مع سلوك العميل المرجعي.
الإصلاح الثاني في الإجماع طبق قواعد قبول العميل المرجعي للتجمع الثابت (static pool) أثناء إعادة البناء والتحقق من المقترحات. هذه القواعد ترفض معاملات blob، وبعض تفويضات EIP-7702، والمعاملات التي تتجاوز 128 كيلوبايت، والعمولات (tips) الأقل من 1 wei، وكلها شروط قد تجعل neox-rs يقبل أو يقترح كتلاً يرفضها العميل المرجعي.
الإصلاح الثالث عالج مشكلة اقتطاع الارتفاع (height truncation) 32-bit في اختيار dBFT الأساسي. العميل المرجعي يخزن ارتفاع الكتلة كعدد صحيح غير موقع 32-bit عند اختيار المدقق الذي يمكنه الاقتراح. بدون هذا الاقتطاع، كان neox-rs يختلف على المقترح بدءاً من ارتفاع الكتلة 4,294,967,296.
إلى جانب إصلاحات الإجماع، تم تحسين سرعة الاستجابة (liveness). مؤقت dBFT يعود الآن إلى فترة كتلة واحدة عندما يسجل العقد مساهمته PreCommit أو Commit، متطابقاً مع سلوك العميل المرجعي ومحسناً سرعة التعافي بعد الاضطرابات. بالإضافة إلى ذلك، رسائل dBFT الموثقة التي تصل لارتفاعات أو نطاقات مستقبلية يتم الآن تخزينها مؤقتاً وإعادة تشغيلها عندما تتقدم الجولة، بدلاً من إسقاطها، مما يمنع انتهاء المهلة غير الضرورية.
الامتثال للبروتوكول والهجرة
الإصدار 2.4.3 الذي صدر في 26 يوليو أصلح مشكلتين غير متعلقتين بالإجماع. الأولى فرضت قيوداً مناسبة على TTL لطلبات blob sidecar. سابقاً، كان neox-rs يقبل أي قيمة TTL حتى 255، مما تسبب في إرسال طلبات خارج النطاق قد تنهي الاتصالات مع عملاء العميل المرجعي. الثانية طبقت توحيد كلمة المرور وفقاً لـ EIP-2335 أثناء هجرة مخزن Geth، لإصلاح فشل للمدققين الذين يحتوي كلمات المرور الخاصة بهم على أحرف غير ASCII أو أحرف تحكم.
التحقق والحالة الحالية
اعتباراً من الإصدار v2.4.3، أعاد neox-rs تنفيذ جميع كتل الشبكة الرئيسية البالغ عددها 7,214,807 كتلة دون أي أخطاء في جذور الحالة. مسار العقدة الكاملة غير المدققة (non-validator) أصبح الآن مؤهلاً لتقييم الإنتاج من قبل المشغلين المستقلين، بعد ترقيته من حالة التقييم التجريبي للإصدارات rc.
وضع المدقق (Validator mode) لا يزال تجريبياً. استدعاءات مشاركة DKG على شبكة اختبار مكونة من 9 عملاء وصلت إلى المدقق المكون من 7 رسائل ولكنها ارتدت مع خطأ CommitmentInvalid(). لم يتحقق أي انتقال بين جولات DKG في الاختبارات المختلطة بين العملاء. علامة --validator.experimental لا تزال إلزامية على الشبكات العامة، والمراجعة الأمنية من الإصدار rc.5 تواصل التوصية بإجراء تدقيق أمني مستقل من طرف ثالث قبل أي نشر للمدقق على الشبكة الرئيسية.
الأسئلة الشائعة (FAQ)
ما هو الإصدار المستقر الجديد neox-rs وماذا يعني؟
neox-rs هو أول عميل بديل لشبكة Neo X مبني على لغة Rust. الإصدار المستقر الجديد v2.4.3 يعني أن العميل أصبح جاهزاً للإنتاج كعقدة كاملة غير مدققة، بعد أن تحقق من ملايين الكتل دون أخطاء.
هل يمكنني استخدام neox-rs كمدقق (Validator) على الشبكة الرئيسية؟
لا، وضع المدقق لا يزال تجريبياً ويتطلب علامة --validator.experimental. لم يتم تحقيق انتقال كامل لجولات DKG في الاختبارات المختلطة، ويُنصح بإجراء تدقيق أمني مستقل قبل أي استخدام كمدقق على الشبكة الرئيسية.
ما هي أبرز الإصلاحات في هذا الإصدار؟
الإصدار الجديد أصلح أربعة اختلافات في الإجماع (Consensus) تجعل neox-rs متوافقاً تماماً مع العميل المرجعي، منها إصلاح مشكلة إعادة بناء مغلفات Anti-MEV ومشكلة اقتطاع الارتفاع في اختيار المدقق. كما أصلح مشكلات في حدود TTL وكلمات المرور أثناء الهجرة.
