غالبًا ما يُقدَّم دعم EVM باعتباره مكسبًا للتوافق: المزيد من المحافظ، والمزيد من الأدوات، والمزيد من مطوري Solidity. لكن هذا الإطار يُخفي سؤالًا معماريًا أكبر — هل ينبغي أن تحدد دراية المطورين أيضًا مكان استقرار نظام مالي؟

تُفصل مكدس Dusk الحالي بين هذه الخيارات. يوفّر DuskEVM تنفيذًا متوافقًا مع EVM يتم تسويته عبر DuskDS، بينما يقوم DuskVM بتشغيل عقود Rust/WASM مباشرةً على L1. يظل DuskDS هو أساس التسوية وتوافر البيانات. وهذا يجعل توافق EVM خيارًا للتنفيذ وليس تعريفًا للطبقة الأساسية.

المغزى هنا أكثر إثارة من مجرد القول: «يدعم Dusk جهازيْن افتراضيين». إذ يمكن لتطبيق مُنظَّم أن يختار أدوات EVM المألوفة دون أن يتطلب الأمر أن تصبح طبقة التسوية نفسها على هيئة EVM.

وفي الوقت نفسه، يمكن للمهام التي تحتاج وصولًا مباشرًا إلى نماذج معاملات Dusk على L1، أو قدرات الخصوصية أو الإثباتات بالمعرفة الصفرية، أن تظل أصلية.

المقايضة تكمن في التنسيق. إن مساريْن للتنفيذ لا يجعلان قدراتهما متطابقة، ولا يزال على المطورين تحديد ما الذي ينبغي أن ينتمي إلى ضمانات التنفيذ، وما الذي يجب أن يُرسَّخ في التسوية.

لذلك فإن اختبار التعديل الحقيقي ليس عدد البيئات التي يدعمها Dusk. بل هو ما إذا كان يمكن أن يتغير التنفيذ دون أن يؤدي ذلك إلى تجزئة افتراضات التسوية الكامنة تحته.

@Dusk $DUSK #dusk $BTW $ROBO