#dusk @Dusk لم يكن “Dusk” مضطرًا فعلًا إلى بناء DuskEVM على الإطلاق. فهو بالفعل يملك بيئة تنفيذ أصلية خاصة به، DuskVM، تعمل عبر تشغيل Rust مُجمَّعًا إلى WASM بدلًا من Solidity. إن وجود كليهما جنبًا إلى جنب، بدلًا من اختيار أحدهما والالتزام الكامل به، يخبرك بشيء عن الهدف الذي صُمم كل منهما من أجله فعليًا، وما الذي تم التنازل عنه لصالح ذلك.

DuskVM هو المسار الأصلي. يمنحك Rust وWASM تحكمًا على مستوى أقل، وخصائص أداء أكثر إحكامًا عادةً، ووصولًا مباشرًا إلى أي بدائيات خاصة بـ Dusk التي تُتاح للطبقة الأساسية، دون المرور عبر طبقة توافق للوصول إليها. المقايضة واضحة بمجرد أن تقولها: في عالم التشفير، يكاد لا أحد يعرف Rust بالطريقة التي يعرف بها Solidity، وبناءً على DuskVM يعني تعلم نظام بيئي كامل بدلًا من جلب نظام قائم معك.

أما DuskEVM فموجود تحديدًا لإزالة هذه العائق. Solidity هي لغة عقود ذكية الأكثر شهرة على نطاق واسع في الصناعة بفارق كبير، وتوافق EVM يعني أن الأدوات القائمة، وعادات المطورين القائمة، وقوالب العقود المدققة القائمة يمكن أن تنتقل—إلى حد كبير—كما هي. المقابل هو أنك الآن تعمل على جهاز افتراضي لم يُبنَ أصلًا لهذا السلسلة، مع وجود طبقة إضافية: بنية الـ rollup تم تغطيتها سابقًا، وهي تقف بين عقدك وضمانات التسوية الأساسية الموجودة تحته.

لذا، فإن الاختيار الحقيقي الذي يُعرض ليس “الأفضل مقابل الأسوأ”، بل “أي قيد تريد.” DuskVM يبدل الألفة لدى المطورين بتكامل أصلي أكثر إحكامًا. وDuskEVM يضحّي بجزء من ذلك الإحكام الأصلي مقابل وصول فوري إلى النظام البيئي الكامل لـ Solidity الموجود بالفعل، وإلى الجميع ممن يتقنونها.

فبالنسبة لمشروع يقوم فعليًا ببناء بنية تحتية مالية منظَّمة على Dusk، هل يأتي هذا الاختيار في معظم الأحيان لِصالح ألفة المطورين بالفطرة، أم توجد حالات استخدام تقنية محددة يكون فيها مسار DuskVM الأصلي هو الخيار الأفضل بوضوح رغم مطالبة المطورين بتعلم شيء جديد.
$DUSK