لمّا كنتُ أطابق وثائق التطوير الأحدث @Dusk فقط حينها فكّكت سوء فهم شائعًا: DuskEVM و DuskVM ليستا نفس الآلة الافتراضية مع مسمّيين مختلفين، وليستا أيضًا “EVM جديد أتى فألغى السلسلة الأصلية”. ما تقدّمه الوثائق للمطوّرين هو مساران للتنفيذ: من يتعامل مع تطبيقات مألوفة مع Solidity وFoundry وHardhat يمضي إلى DuskEVM؛ ومن يحتاج إلى منطق يلامس أصول L1 أو Phoenix/Moonlight أو Rust/WASM أو قدرات معرفة-صفرية، فمساره هو DuskVM.
DuskEVM هو مسار OP Stack؛ التنفيذ والأدوات قدر الإمكان تكون قريبة من نظام بيئة الإيثيريوم، ثم تُوكَل التسوية ونشر البيانات إلى DuskDS، و$DUSK يستمر كـ gas. أما DuskVM فيعمل مباشرة على L1 لتنفيذ عقود WASM، وهو أقرب إلى نموذج المعاملات الأصلي وإلى قدرات البروتوكول. الأول يهدف إلى خفض كلفة الانتقال، والثاني يحافظ على القدرة على التميّز؛ هذا يحل سؤال “هل سيأتي المطوّرون؟”، وذاك يحل سؤال “إذا جاءوا، هل يمكنهم أن يفعلوا أشياء لا تُنجَز كما ينبغي عبر EVM العادي”.
لكن المسارين سيوجِدان أيضًا تكاليف جديدة. كيفية عبور الأصول بين الطبقات، وأين توضع حالة نفس الأعمال، وكيف تتصل تطبيقات EVM بعملية السرّية الخاصة بـ Hedger—لا تنجزها تلقائيًا عبارة مثل “مدعومة بتجزئة/ت modularization”. إرشادات الجسر عبر الطبقات الرسمية لـ DuskEVM تُظهر حاليًا بوضوح سير العمل على شبكة الاختبار فقط؛ أمّا الاسترجاع/السحب فيتطلّب المرور بثلاث عمليات على السلسلة: البدء، ثم الإثبات، ثم التأكيد النهائي، ولا يمكن أن تُكتب مخططات المعمارية مسبقًا على أنها “تجربة سلسة بلا احتكاك” في الشبكة الرئيسية.
وعند تقييم المسار متعدد الطبقات لـ #dusk ، لن أحسب فقط عدد اللغات المدعومة؛ بل سأركّز على أين تتم فعليًا عملية التطبيق داخل أي طبقة، وكيف تتم استعادة الأخطاء عند فشل عبور الطبقات، وهل يمكن للمطوّرين استدعاء ميزات الخصوصية مباشرة. هل ينبغي أن تبدأ السلسلة الجديدة باستخدام EVM لسرعة تبنّي النظام البيئي، أم أن تبدأ بحماية التكامل الكامل للتقنية الأصلية؟
DuskEVM هو مسار OP Stack؛ التنفيذ والأدوات قدر الإمكان تكون قريبة من نظام بيئة الإيثيريوم، ثم تُوكَل التسوية ونشر البيانات إلى DuskDS، و$DUSK يستمر كـ gas. أما DuskVM فيعمل مباشرة على L1 لتنفيذ عقود WASM، وهو أقرب إلى نموذج المعاملات الأصلي وإلى قدرات البروتوكول. الأول يهدف إلى خفض كلفة الانتقال، والثاني يحافظ على القدرة على التميّز؛ هذا يحل سؤال “هل سيأتي المطوّرون؟”، وذاك يحل سؤال “إذا جاءوا، هل يمكنهم أن يفعلوا أشياء لا تُنجَز كما ينبغي عبر EVM العادي”.
لكن المسارين سيوجِدان أيضًا تكاليف جديدة. كيفية عبور الأصول بين الطبقات، وأين توضع حالة نفس الأعمال، وكيف تتصل تطبيقات EVM بعملية السرّية الخاصة بـ Hedger—لا تنجزها تلقائيًا عبارة مثل “مدعومة بتجزئة/ت modularization”. إرشادات الجسر عبر الطبقات الرسمية لـ DuskEVM تُظهر حاليًا بوضوح سير العمل على شبكة الاختبار فقط؛ أمّا الاسترجاع/السحب فيتطلّب المرور بثلاث عمليات على السلسلة: البدء، ثم الإثبات، ثم التأكيد النهائي، ولا يمكن أن تُكتب مخططات المعمارية مسبقًا على أنها “تجربة سلسة بلا احتكاك” في الشبكة الرئيسية.
وعند تقييم المسار متعدد الطبقات لـ #dusk ، لن أحسب فقط عدد اللغات المدعومة؛ بل سأركّز على أين تتم فعليًا عملية التطبيق داخل أي طبقة، وكيف تتم استعادة الأخطاء عند فشل عبور الطبقات، وهل يمكن للمطوّرين استدعاء ميزات الخصوصية مباشرة. هل ينبغي أن تبدأ السلسلة الجديدة باستخدام EVM لسرعة تبنّي النظام البيئي، أم أن تبدأ بحماية التكامل الكامل للتقنية الأصلية؟
