أشغّل سكربت بايثون صغيرًا على لابتوبي في إسلام أباد يقوم بعمليات تجزئة ثقيلة لمشروع جانبي، وقد حاولت ذات مرة نقله إلى بيئة معزولة (sandbox) ظننت أنه سيعمل بنفس السرعة تقريبًا لأن المنطق لم يتغير. لكن الأمر كان أبطأ بشكل ملحوظ، وحتى قرأت عن آلة Dusk الافتراضية Piecrust لم أفهم بالفعل لماذا يحدث ذلك على المستوى التقني.

افترضت أن تنفيذ العقود الذكية داخل آلة افتراضية WASM يعمل بسرعة قريبة من السرعة الأصلية (native)، لأن WASM يُسوَّق عادةً كأداء قريب من الأداء الأصلي.
هذا غير دقيق بالنسبة لعمليات التشفير تحديدًا. الأبحاث التي استشهدت بها الورقة البيضاء تُظهر أن تنفيذ WASM قد يعمل بنسبة 45 إلى 255 بالمئة أبطأ من الشيفرة الأصلية للمعالجات/التطبيقات المعقدة، وذلك أساسًا بسبب إدارة الذاكرة المُؤمَّنة (virtualized memory management) ومعالجة تعليمات إضافية داخل الحماية (sandbox).

وهذا بالضبط سبب أن Piecrust لا يشغّل أشياء مثل التحقق من إثباتات ZK أو التجزئة أو فحوصات التوقيع داخل حيز WASM على الإطلاق. بل يعرض دوالًا مضيفة (host functions) بدلًا من ذلك، مع استدعاءات مباشرة للنسخة الأصلية (native) لعمليات مثل hash وverify_plonk وverify_groth16_bn254 وverify_schnorr وverify_bls. يستدعي العقد الشيفرة الأصلية للمهام التشفيرية المكلفة، ثم يعود إلى WASM لكل شيء آخر. هذا تقسيم معماري مقصود، وليس مجرد حل بديل.

ما تعترف به الورقة البيضاء صراحةً هو أن Dusk لم يقم بعد بقياس/تحديد مقدار التوفير الفعلي في استهلاك الطاقة من إعداد كهذا. لذلك لا أستطيع أن أقدم لك رقم كفاءة حقيقي، لأن Dusk نفسها لم تنشر رقمًا بعد.

الاختبار الحقيقي لـ DUSK هو ما إذا كان نهج الدوال المضيفة هذا سيظل متماسكًا مع تزايد تعقيد العقود على الشبكة الرئيسية (mainnet).

هل قام أي شخص بإجراء اختبارات قياسية (benchmark) لاستدعاءات host function في Piecrust مقارنةً بالتنفيذ الخالص داخل WASM بنفسه؟
@Dusk #dusk $DUSK