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