في الليلة الماضية عندما كنت أتصفح وثائق Dusk، اكتشفت فقط أنني كنت أفسّر عبارة «دعم EVM» على نحو سهل وبسيط أكثر من اللازم. لم تقم Dusk بوضع كل العقود داخل جهاز افتراضي واحد: يمكن للمطورين الذين يعرفون Solidity وFoundry استخدام DuskEVM، والدفع مقابل Gas باستخدام DUSK، ثم يتم تسليم بيانات الدفعات والتعهدات بالحالات إلى DuskDS لإجراء التسوية؛ أما إذا كانت هناك حاجة إلى خصوصية أصلية وقدرات على مستوى المعرفة الصفرية، أو عقود تتحكم بأصول على مستوى البروتوكول، فسيتم تشغيلها مباشرة على DuskVM باستخدام Rust/WASM.

لقد فهمتها على أنها جهازان لخدمة عمليات تابعان لجهة تداول واحدة. أحدهما يحتفظ بأزرار مألوفة، فيكون الانتقال أسرع؛ والآخر أقرب إلى الخزانة الأساسية، ويمكنه استدعاء قواعد أكثر «أصالة»، وفي النهاية يعود كلاهما إلى قاعدة تسوية موحدة للتحقق من دفتر الأستاذ. وهذا المفاضلة أهم من مجرد عبارة «التوافق مع EVM»، لأنها تفصل بين كفاءة التطوير والقدرات الأصلية.

لكن المسارين يضيفان أيضًا تعقيدًا في الربط والتفاعل عبر الطبقات، كما يتطلبان تحديدًا دقيقًا للحالة. توضح الوثائق الرسمية أن «التغليف السريع» في DuskEVM لا يعني أن التسوية قد تمّت بالفعل على DuskDS، ولن أكتفي بالنظر إلى أن الصفحة تعرض النجاح وأعتبر أن الأمر قد اكتمل نهائيًا. لاحقًا يجب التحقق مما إذا كانت تجربة عبر الطبقات سلسة، وهل الأدوات ناضجة، وهل كمية العقود الفعلية تنمو. يقدّم التصميم خيارًا، واعتماد الخيار هو ما يعطي الإجابة.

@Dusk $DUSK #dusk