لفتت انتباهي عمليات التحويل البالغ عددها 280 عملية، لكنني انتهيت إلى إيلاء اهتمام أكبر لما يحدث حولها.

لقد راجعت أحدث أعمال إنهاء (sign off) شبكة Dusk Hyperlane ذات الصلة بالعمل، وكذلك الاختبارات حتى الآن وتبيّن أنها تبدو متينة. نجح أحدث إعادة إنتاج نظيفة في اجتياز عمليات بناء العقد، واختبارات الجهاز الظاهري (VM)، واختبارات المعاملات، وفحوصات وكيل (agent) Hyperlane. بعد ذلك، عمل اختبار التحمل عالي الحجم لمدة 7 دورات، مع 20 عملية تحويل من EVM إلى Dusk و20 عملية تحويل من Dusk إلى EVM في كل دورة. وهذا يعني 280 عملية تحويل إجمالاً خلال 7,282 ثانية قبل انتهاء نافذة الاختبار التي مدتها 120 دقيقة.

لكن ما وجدته أكثر أهمية هو قائمة التحقق الخاصة بالإصدار (production) التي كانت إلى جانب تلك النتائج. ما زال تحديد حيازة (custody) المُوقّع (production signer) قيد القرار. كما توجد أيضاً قرارات مفتوحة بشأن استرداد الأموال الموضوعة في حساب إيداع معلق (pending escrow recovery)، ومدة استمرار اختبار التحمل (soak)، وكيف ينبغي أن تعمل إعدادات التكامل المستمر (CI) وقابلية إعادة الإنتاج (reproducibility). من السهل إغفال هذه الأمور عندما تكون النتيجة الرئيسية اختباراً ناجحاً، لكن هذه هي الأشياء التي أرغب في فهمها قبل أن يشارك سيولة حقيقية.

سؤال المُوقّع يصعب تجاهله بشكل خاص بعد ما حدث مع الجسر القديم من Dusk إلى EVM في يناير. حصل مهاجم على وصول إلى محفظة توقيع الجسر، وسرق DUSK منها، ثم نقل جزءاً من الأموال المسروقة عبر الجسر إلى BNB Smart Chain. كان Dusk واضحاً بأن الحادث كان اختراقاً لمحفظة الجسر، وليس استغلالاً للإجماع أو البروتوكول في Dusk. ثم تمت إعادة تصميم الجسر لاحقاً مع فصل أقوى بين عملية التوقيع، والتعامل مع الأحداث (event handling)، وإطلاق الأموال (fund release)، بالإضافة إلى ضوابط أكثر إحكاماً للرصيد والاسترداد.

لذلك لا أنظر إلى 280 عملية تحويل على أنها إشارة خضراء أو حمراء. فهي تُظهر أن النظام يتم اختباره بجدية. ما يهمني الآن هو كيف يفترض أن يتصرف النظام عندما يحدث خطأ، ومن يتحكم في الأجزاء الحساسة، وكيف تتم معالجة الاسترداد.

هذا هو ما أود أن يتم حسمه قبل اعتبار Dusk Hyperlane بنية تحتية لسيولة ذات مغزى.

$DUSK @Dusk #dusk