عندما كنت أقرأ وثائق W3sper الخاصة بـ Dusk @Dusk Dusk، كنت قد اعتبرت DuskVM استعلامًا عن واجهة JSON عادية. يقوم تجميع عقد Forge بإنتاج data-driver WASM أيضًا؛ يقوم التطبيق بالتسجيل لدى W3sper اعتمادًا على معرّف العقد. يقوم الـ driver بترميز الإدخال إلى بايتات ABI، ثم يفك ترميز قيمة الإرجاع التي يعيدها العقد بعد ذلك.

لقد عاملته مثل ترجمان في مكتب خدمة أرضية بالمطار. يقول المسافر JSON، لكن ساحة الإقلاع لا تتعرف إلا على تنسيق تحميل ثابت؛ يقوم مكتب الترجمة بتغليف الطلب وفقًا لـ schema، ثم عند رحلة العودة يفكّ التغلّيف ليستخرج المخرجات والأحداث. عند إرسال raw bytes عبر HTTP، يتم تسليمها مباشرة إلى العقد؛ وعند إرسال JSON، يتم تحويلها تلقائيًا فقط عندما يكون الـ driver متاحًا. يمكن استخدام get_version للتحقق من الإصدار.

من فضلك أخفِ ذلك خلف الترقية. قد يُرجع الـ driver القديم نجاحًا، لكنه قد يفسر البيانات وفقًا لـ ABI غير محدث. في البيانات الوصفية، فإن driver_available و driver_signature لا يساعدانني إلا في التأكد من هوية الدرايفر. سأثبت تجزئة الملف، وفي testnet سأقارن نفس المدخلات بين raw bytes والنتيجة بعد فك الترميز. كون الصفحة قابلة للقراءة لا يثبت سوى أن سلسلة الترجمة تعمل؛ ما تزال حالة الأصول تتطلب تحققًا مستقلًا.

#dusk $DUSK