اعتبار نجاح نشر العقد بوصفه إتمام التطوير يُعدّ خطأ شائعًا يمكن أن يؤدي إلى سوء تقدير على Dusk. بالرجوع إلى وثائق DuskVM التابعة لـ @Dusk خطوةً خطوة، توقفت عند خانة Forge: فهي تُولّد ABI وschema وdata driver من كود Rust مع التعليقات؛ والاثنان الأخيران ليسا ملفات مرفقة كإكسسوار، بل هما مدخلان تقرأ من خلالهما الحالة الموجودة على السلسلة. هذه التفاصيل جعلتني أُعيد تقييم تقدم التطوير: إن كان WASM يمكنه التنفيذ فهذا يعني فقط أن القواعد قد دُوّنت؛ أما وصف الواجهة وعمليات القراءة (drivers) فإذا لم تُسلَّم بنفس الإصدار، فسيبقى بإمكان الواجهة الأمامية والسكريبتات والفهرسة أن “تخمّن” شكل الحالة.
أكثر ما يعرّض للمشاكل هو الترقية. نشر الفريق عقدًا جديدًا، لكن data driver ظلّ على إصدار قديم؛ فتنجح المعاملات كالمعتاد، وقد تصبح الأرصدة أو الحقول أو الأحداث التي تعرضها الصفحة متأخرة بالفعل. سيقوم المستخدمون بإعادة تحميل الصفحة مرارًا، ويتحقق المهندسون أولًا من العقدة، ثم يشرح فريق خدمة العملاء: “لا توجد مشكلة على السلسلة”. لكن الخلل الحقيقي يكون بين حالة العقد وعقد القراءة (قراءة العقود). إعادة تشغيل الخدمة لا تحل مشكلة عدم تطابق الإصدارات؛ غالبًا ما يلزم إعادة البناء والتحقق، ثم جعل التطبيق يعتمد على الـ driver المطابق.
لهذا لا أتعامل مع Forge كأداة تفهم فقط أنها توفر وقت إنشاء الأدوات (scaffolding). إنها تضع “يمكن للعقد أن يعمل” و“يمكن للتطبيق أن يفسر العقد بشكل صحيح” ضمن سلسلة تسليم واحدة متسقة؛ وما يقلّه ذلك ليس كل تكلفة التكامل، بل يقلل مقدار التخمين عبر الأدوار. بالنسبة لإيكوسستم $DUSK ، ما يستحق النظر لاحقًا أكثر هو ما إذا كانت مشاريع الأمثلة وخطوات النشر ستُظهر بوضوح علاقة إصدارات ABI وschema وdata driver؛ وإذا اعتُبرت هذه الخطوة خيارًا، فقد يحصل المطوّرون ما يزال على عقد يمكن تنفيذه، لكنه يصعب استخدامه بشكل موثوق.#dusk 👻👻👻