#dusk $DUSK @Dusk
لقد تتبّعت كيف يقسّم DuskVM وDuskEVM العمل فعليًا على Dusk، إذ إنهما تنفّذان العقود، لكنهما بوضوح ليستا قابلتين للتبادل.
يُشغّل DuskVM عقود Rust/WASM، المبنية على Wasmtime، مباشرةً على L1 لدى Dusk. إنه المسار المصمَّم للعقود التي تحتاج وصولًا مباشرًا إلى نماذج معاملات Dusk الخاصة بها، أو ميزات الخصوصية، أو قدرات الإثباتات بالمعرفة الصفرية — حيث تعيش دوال الاستضافة الملائمة للـ ZK لدى Piecrust (PLONK وGroth16 وBLS) هنا تحديدًا.
يعمل DuskEVM في مكان آخر تمامًا. إنه بيئة مكافئة لـ EVM مبنية على OP Stack — وقد تم تأكيد معرف سلسلة الاختبار (chain ID) على أنه 745 في وثائق Dusk الخاصة — ما يسمح للمطوّرين بنشر عقود Solidity القياسية باستخدام MetaMask أو Hardhat أو Foundry، مع تسوية ونشر البيانات مرةً أخرى عبر DuskDS كـ blobs، عبر مُسلسِل (sequencer) ومُجمِّع (batcher) بدلًا من تشغيلها بشكل مستقل.
لقد عزلت ما يفرّق بينهما بما يتجاوز مجرد اللغة. تحصل عقود DuskVM على الخصوصية وبُنى ZK-الأولية بشكل فطري على طبقة التنفيذ. تحصل عقود DuskEVM على توافق كامل مع أدوات التطوير، ويدفع المستخدمون الغاز في DUSK هناك أيضًا، لكن كل ذلك يمر عبر طبقة تُسَوّي في مكان آخر بدلًا من العمل جنبًا إلى جنب بشكل أصيل مع نماذج معاملات Dusk الخاصة.
كلاهما يُسَوّي عبر القاعدة نفسها — DuskDS — وكلاهما في النهاية يدفع الغاز في DUSK. لا يحلّ أحدهما محل الآخر؛ فلكل واحد منهما وجود لأنه لا يستطيع أن يُنجز وظيفة الآخر على نحو جيد فعلًا.
لذا فإن الاختيار الحقيقي بالنسبة لأي مُنشئ ليس «أيّهما أفضل». بل ما إذا كانت العقد يحتاج تنفيذًا بخصوصية أصيلة أو أدوات EVM مألوفة يمكن التحقق من chain-ID — وقد أنشأ Dusk مسارين منفصلين بدل إجبار بيئة واحدة على القيام بكليهما.
هل يخدم الحفاظ على بيئتي تنفيذ منفصلتين بشكل حقيقي المُنشئين بشكل أفضل من اختيار واحدة وتطويرها بالكامل؟
لقد تتبّعت كيف يقسّم DuskVM وDuskEVM العمل فعليًا على Dusk، إذ إنهما تنفّذان العقود، لكنهما بوضوح ليستا قابلتين للتبادل.
يُشغّل DuskVM عقود Rust/WASM، المبنية على Wasmtime، مباشرةً على L1 لدى Dusk. إنه المسار المصمَّم للعقود التي تحتاج وصولًا مباشرًا إلى نماذج معاملات Dusk الخاصة بها، أو ميزات الخصوصية، أو قدرات الإثباتات بالمعرفة الصفرية — حيث تعيش دوال الاستضافة الملائمة للـ ZK لدى Piecrust (PLONK وGroth16 وBLS) هنا تحديدًا.
يعمل DuskEVM في مكان آخر تمامًا. إنه بيئة مكافئة لـ EVM مبنية على OP Stack — وقد تم تأكيد معرف سلسلة الاختبار (chain ID) على أنه 745 في وثائق Dusk الخاصة — ما يسمح للمطوّرين بنشر عقود Solidity القياسية باستخدام MetaMask أو Hardhat أو Foundry، مع تسوية ونشر البيانات مرةً أخرى عبر DuskDS كـ blobs، عبر مُسلسِل (sequencer) ومُجمِّع (batcher) بدلًا من تشغيلها بشكل مستقل.
لقد عزلت ما يفرّق بينهما بما يتجاوز مجرد اللغة. تحصل عقود DuskVM على الخصوصية وبُنى ZK-الأولية بشكل فطري على طبقة التنفيذ. تحصل عقود DuskEVM على توافق كامل مع أدوات التطوير، ويدفع المستخدمون الغاز في DUSK هناك أيضًا، لكن كل ذلك يمر عبر طبقة تُسَوّي في مكان آخر بدلًا من العمل جنبًا إلى جنب بشكل أصيل مع نماذج معاملات Dusk الخاصة.
كلاهما يُسَوّي عبر القاعدة نفسها — DuskDS — وكلاهما في النهاية يدفع الغاز في DUSK. لا يحلّ أحدهما محل الآخر؛ فلكل واحد منهما وجود لأنه لا يستطيع أن يُنجز وظيفة الآخر على نحو جيد فعلًا.
لذا فإن الاختيار الحقيقي بالنسبة لأي مُنشئ ليس «أيّهما أفضل». بل ما إذا كانت العقد يحتاج تنفيذًا بخصوصية أصيلة أو أدوات EVM مألوفة يمكن التحقق من chain-ID — وقد أنشأ Dusk مسارين منفصلين بدل إجبار بيئة واحدة على القيام بكليهما.
هل يخدم الحفاظ على بيئتي تنفيذ منفصلتين بشكل حقيقي المُنشئين بشكل أفضل من اختيار واحدة وتطويرها بالكامل؟
