الآن في هذين اليومين أعادَ رسمُتُ مكوّنات Core لـ @Dusk بالكامل، إلى أن تمكنت من فصل أسماء DuskVM وDuskEVM وDuskDS. في البداية اعتقدتُ أن الأمر مجرد «سلسلة واحدة متوافقة مع نوعين من الأجهزة الافتراضية»، لكن التقسيم الفعلي أقرب إلى ثلاث طبقات: DuskDS يختص بالإجماع والنهائية وإتاحة البيانات؛ DuskVM يجعل عقود Rust/WASM تعمل مباشرة على L1؛ وDuskEVM هو بيئة تنفيذ مكافئة لـ EVM مبنية على OP Stack، تسند التسوية ونشر البيانات إلى DuskDS.
وهذا يعني أن المطورين ليسوا مضطرين للاختيار «بدون تفكير» بين خيارين. إذا كانت لديك عقود Solidity موجودة بالفعل، وتعتمد على محافظ EVM وسلاسل الأدوات، فاختيار DuskEVM ستكون تكلفته أقل؛ أما إذا كنت ستتعامل مباشرة مع أصول L1، أو مع نموذج الخصوصية Phoenix، أو قدرات المعرفة الصفرية (zero-knowledge)، أو تريد تحكمًا أعمق على مستوى البروتوكول، فـ DuskVM هو المدخل الأصلي. المساران يشتركان في قاعدة التسوية، لكن هذا لا يعني أن الوظائف وافتراضات الأمان متطابقة تمامًا.
أنا متحفظ قليلًا تجاه مقولة: «EVM compatible = سيتحرك النظام البيئي تلقائيًا إلى الداخل». فالتوافق لا يُخفض سوى عتبة النشر، ولا يمكنه أن يُغني عن الاتصال بالمحافظ، أو RPC مستقر، أو مفهرِس (indexer)، أو السيولة، أو المستخدمين الحقيقيين. وبالمقابل، التركيز فقط على الأصالة في Rust/ZK غير كافٍ أيضًا؛ فالأدوات قد تكون قاسية جدًا، ولن يعيد المطورون كتابة منتجاتهم بالكامل من أجل النزاهة التقنية.
لذلك، عند النظر إلى التقدم التقني لـ $DUSK ، أراه سيُفكك المؤشرات: هل لدى DuskEVM تطبيقات Solidity من طرف ثالث؟ وهل لدى DuskVM عقود غير رسمية؟ وهل مسار التسوية إلى DuskDS في الجانبين مستقر؟ وإذا كانت الخندق الحصين لـ #dusk حقيقية بالفعل، فالمفترض أنها ستكون: «الناس المألوفون بالأدوات يمكنهم الدخول، وعند الحاجة إلى الخصوصية يمكنهم النزول إلى المستوى التالي»، وليس مجرد تكديس ثلاثة أسماء جديدة معًا. أنتم ستختارون أولًا التوافقية، أم القدرات الأصلية؟
وهذا يعني أن المطورين ليسوا مضطرين للاختيار «بدون تفكير» بين خيارين. إذا كانت لديك عقود Solidity موجودة بالفعل، وتعتمد على محافظ EVM وسلاسل الأدوات، فاختيار DuskEVM ستكون تكلفته أقل؛ أما إذا كنت ستتعامل مباشرة مع أصول L1، أو مع نموذج الخصوصية Phoenix، أو قدرات المعرفة الصفرية (zero-knowledge)، أو تريد تحكمًا أعمق على مستوى البروتوكول، فـ DuskVM هو المدخل الأصلي. المساران يشتركان في قاعدة التسوية، لكن هذا لا يعني أن الوظائف وافتراضات الأمان متطابقة تمامًا.
أنا متحفظ قليلًا تجاه مقولة: «EVM compatible = سيتحرك النظام البيئي تلقائيًا إلى الداخل». فالتوافق لا يُخفض سوى عتبة النشر، ولا يمكنه أن يُغني عن الاتصال بالمحافظ، أو RPC مستقر، أو مفهرِس (indexer)، أو السيولة، أو المستخدمين الحقيقيين. وبالمقابل، التركيز فقط على الأصالة في Rust/ZK غير كافٍ أيضًا؛ فالأدوات قد تكون قاسية جدًا، ولن يعيد المطورون كتابة منتجاتهم بالكامل من أجل النزاهة التقنية.
لذلك، عند النظر إلى التقدم التقني لـ $DUSK ، أراه سيُفكك المؤشرات: هل لدى DuskEVM تطبيقات Solidity من طرف ثالث؟ وهل لدى DuskVM عقود غير رسمية؟ وهل مسار التسوية إلى DuskDS في الجانبين مستقر؟ وإذا كانت الخندق الحصين لـ #dusk حقيقية بالفعل، فالمفترض أنها ستكون: «الناس المألوفون بالأدوات يمكنهم الدخول، وعند الحاجة إلى الخصوصية يمكنهم النزول إلى المستوى التالي»، وليس مجرد تكديس ثلاثة أسماء جديدة معًا. أنتم ستختارون أولًا التوافقية، أم القدرات الأصلية؟
