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