لتقييم تقدم مشروعٍ ما، لا يهمني ما يقولونه عن الشبكة الرئيسية، بل يهمني ما يظهر في مستودع GitHub الخاص به. في كود @Dusk توجد إشارة صادقة جدًا: ففي قضايا (issues) مستودع الوثائق مكتوب أنه بعد إدخال بنية معيارية/وحداتية (modular)، يُنصح للمطورين باستخدام DuskEVM، لكن معظم وثائق المطورين الحالية ما زالت تتحدث عن DuskVM. وهذا يعني أن اتجاه المنتج قد تغيّر بالفعل، لكن الوثائق والكود لم يلتحقا به بالكامل بعد.
كما تؤكد مستودعات GitHub الرسمية المفتوحة لدى Dusk هذا التباين. فإن dusk-network/rusk هو تنفيذٌ مُرجعي (reference implementation)، وفيه توجد وحدات أساسية مثل dusk-vm وdusk-core وPLONK لإثباتات المعرفة الصفرية (zero-knowledge). لكن مستودع rusk-vm المستقل، الأقرب إلى القدرات الأصلية (native)، لا يحظى بسخونة مماثلة؛ إذ تبدو أرقام النجوم (stars) وإشارات التحديث أقل برودة من سرد القصة الرئيسي. بالمقابل، فإن الوثائق الرسمية قد وضعت DuskEVM في أكثر مواضعها سهولة: دليل البدء السريع (quickstart)، وSolidity، وسلسلة أدوات إيثيريوم (Ethereum toolchain). ومشروع يَعِد بخصوصية أصلية وبتطبيقات ذكية (WASM)، لكنه فعليًا يوجّه المطورين الجدد نحو مسار EVM؛ هذا بحد ذاته يمثل موقفًا صامتًا.
#dusk
لم أتعامل مع عدد النجوم كاستنتاج حتى الآن، لأن نشاط الكود يعتمد أيضًا على وتيرة الـ commits، وعدد المساهمين، ومعدل إغلاق الـ issues. لكن هذه الشذرات إذا جُمعت، فالصورة واضحة: $DUSK يتركّز على عملية الانتقال (migration)، والجزء المتعلق بالـ VM الأصلي يبدو أكثر كقدرة يتم الاحتفاظ بها على المدى الطويل، وليس كمدخل تطوير رئيسي يتم الترويج له حاليًا. يلزم في الإعلان الرسمي عن “mainnet coming” وجود إيقاع تسليم كودٍ مناسب يدعمه، وليس الاعتماد فقط على تغيير فهرس الوثائق باستبدال المراجع.
الخلاصة: حاليًا لا تكفي إشارات الكود المنشور لدعم القول بأن “بيئتي تنفيذ” متكافئتان في النضج. إن DuskEVM هو بوضوح الاتجاه الأكثر نشاطًا والأكثر دفعًا، بينما DuskVM يبدو كجزء من الاحتياط لم يتم تلميعه بشكل كافٍ بعد. أما التقدم الحقيقي، فينبغي أن نراقب ما إذا كانت الـ issues الخاصة ببعض المعالم القادمة ستُغلق باستمرار، لا أن ننشغل بعدد المقالات المفاهيمية التي تظهر على الصفحة الرئيسية.
كما تؤكد مستودعات GitHub الرسمية المفتوحة لدى Dusk هذا التباين. فإن dusk-network/rusk هو تنفيذٌ مُرجعي (reference implementation)، وفيه توجد وحدات أساسية مثل dusk-vm وdusk-core وPLONK لإثباتات المعرفة الصفرية (zero-knowledge). لكن مستودع rusk-vm المستقل، الأقرب إلى القدرات الأصلية (native)، لا يحظى بسخونة مماثلة؛ إذ تبدو أرقام النجوم (stars) وإشارات التحديث أقل برودة من سرد القصة الرئيسي. بالمقابل، فإن الوثائق الرسمية قد وضعت DuskEVM في أكثر مواضعها سهولة: دليل البدء السريع (quickstart)، وSolidity، وسلسلة أدوات إيثيريوم (Ethereum toolchain). ومشروع يَعِد بخصوصية أصلية وبتطبيقات ذكية (WASM)، لكنه فعليًا يوجّه المطورين الجدد نحو مسار EVM؛ هذا بحد ذاته يمثل موقفًا صامتًا.
#dusk
لم أتعامل مع عدد النجوم كاستنتاج حتى الآن، لأن نشاط الكود يعتمد أيضًا على وتيرة الـ commits، وعدد المساهمين، ومعدل إغلاق الـ issues. لكن هذه الشذرات إذا جُمعت، فالصورة واضحة: $DUSK يتركّز على عملية الانتقال (migration)، والجزء المتعلق بالـ VM الأصلي يبدو أكثر كقدرة يتم الاحتفاظ بها على المدى الطويل، وليس كمدخل تطوير رئيسي يتم الترويج له حاليًا. يلزم في الإعلان الرسمي عن “mainnet coming” وجود إيقاع تسليم كودٍ مناسب يدعمه، وليس الاعتماد فقط على تغيير فهرس الوثائق باستبدال المراجع.
الخلاصة: حاليًا لا تكفي إشارات الكود المنشور لدعم القول بأن “بيئتي تنفيذ” متكافئتان في النضج. إن DuskEVM هو بوضوح الاتجاه الأكثر نشاطًا والأكثر دفعًا، بينما DuskVM يبدو كجزء من الاحتياط لم يتم تلميعه بشكل كافٍ بعد. أما التقدم الحقيقي، فينبغي أن نراقب ما إذا كانت الـ issues الخاصة ببعض المعالم القادمة ستُغلق باستمرار، لا أن ننشغل بعدد المقالات المفاهيمية التي تظهر على الصفحة الرئيسية.
