في السابق كنت أظن أنّه إذا وضعت بلوكتشين عامة واحدة عدة بيئات تنفيذ، فهذا لا يعني سوى توفير طريق إضافي للمطوّرين. لكن بعد تفكيك معماريّة @Dusk ، أدركت أنّ العلاقة بين DuskVM وDuskEVM ليست بهذه البساطة؛ فهما أشبه بمدخلين مصمَّمين لتلبية احتياجات مختلفة. $DUSK
تشغّل DuskVM مباشرةً على Dusk L1، باستخدام Rust/WASM، وهو مناسب لاستدعاء الأصول الأصلية والميزات المتعلقة بالخصوصية وإمكانات ZK. أمّا DuskEVM فيشبه أكثر جسرًا للانتقال، يسمح لمطوّري Solidity بالاستمرار في استخدام المحافظ والأطر وأدوات الاختبار المألوفة. وفي النهاية، تُسلَّم نتائج الطرفين إلى DuskDS لتتولى التسوية. #dusk
وهذا يعني أنّ دور DuskEVM لا يقتصر فقط على تقليل عتبة الهجرة. فمثلًا، إذا كان تطبيق ماليّ عادي يريد أولًا الاستفادة من سلسلة أدوات EVM الناضجة، فيمكنه البدء بـ DuskEVM؛ لكن إذا كان المشروع يتعلّق بأوراق مالية بنظام الخصوصية أو بتحويل أصول مُقيَّدة، أو يحتاج إلى استدعاء قدرات Dusk الأصلية للسرّيات، فلن يكفي التوقّف عند طبقة EVM؛ فالكثير من المنطق لا يزال بحاجة إلى DuskVM.
وهنا يبرز السؤال. لنفترض أن تطبيقًا يحتاج إلى التعامل مع كلٍّ من عقود Solidity والأصول الخصوصية الأصلية في Dusk؛ فأين تكون الحالة الأساسية؟ وكيف تتم المزامنة بين البيئتين؟ ومن الذي يتحقق من الاستدعاءات عبر الطبقات؟ وعند حدوث خطأ، هل سيتعيّن على المطوّرين تتبّع مشاكل العقد، أم مشاكل بيئة التنفيذ، أم مشاكل طبقة التسوية؟ $BTC
لذلك أنا الآن أرى أن تعدد بيئات التنفيذ في Dusk ليس مجرد ميزة توافق. فمن جهة، يتيح دخول عدد أكبر من المطورين؛ ومن جهة أخرى، يضع تحديات تصميم النظام على عاتق فريق التطوير. الشيء الجدير بالملاحظة ليس كم طريقة تنفيذ يقدمها Dusk، بل ما إذا كانت هذه البيئات قادرة على تكوين حدود واضحة بينها—بحيث يعمل المطوّرون على تقليل القرارات غير الضرورية، لا على زيادة تعقيد بنية التطبيق أكثر فأكثر بهدف استدعاء قدرات مختلفة في الوقت نفسه. $ETH